为什么java不提供对象手工释放？

Question

我的意思是java应概提供垃圾自动机制，又提供手工释放，这岂不是更好？

Answer 1

JAVA是一个将安全性作为其设计理念重要组成部分的语言，而手动释放对象是很多隐蔽错误的极大根源，虽然在JAVA中也可以手动调用垃圾回收机制，但这并不是被提倡的，优秀的设计应该就是在他需要被释放的时候就会自动释放。@.@||~

Answer 2

"优秀的设计应该就是在他需要被释放的时候就会自动释放"?
这句话难理解，并且有点勉强。java跨平台是他的思想，为什么它又提供本地代码模式？

Answer 3

当然，你可以把一些不需要使用的对象设成null,但对象所占的内存空间却没有被释放，只是程序中无法再调用它了，最终它们还是要GC来释放空间的。习惯了c/c++的对象随时可以释放，感觉java里面这一点有点奇怪，但虽然有些不方便，但带来了整个系统的运行安全和代码的复杂度，对程序的效率提高有重大意义

Answer 4

如果你想让没用的对像尽早的离开内存，你可以把用完的对象赋为null；告诉GC这个可以回收了，等着GC的回收就成了。

Answer 5

初学者不懂释放对象，或会忘记释放会很有很严重的后果。为了简单易学就有虚拟机来完成了。为什么不及可以手动释放对象有可以由虚拟机来回收呢？
我想主要是因为那样实现起来会很复杂。也可能是因为java设计者认为你已经习惯了自动释放对象了，而且自动释放也能达到运用级的要求，已经不想再去搞手动释放了。

Answer 6

我是菜鸟啊，我多问一句
System.gc();
这个是不是立即执行垃圾回收？也就是手工释放么？

Answer 7

首先不建议使用System.gc()，因为即使是此函数都未必保证垃圾回收机制的启动，其次除非是为了某些非JAVA特性的内存释放，否则不建议使用finalize()函数，以及System.gc()函数的调用。其次，
TO AiQun(爱麇)
    所谓对象应该在他需要被释放的时候就会自动释放，乃是JAVA设计思想之一，JAVA的安全性思想希望你能更多的忘记对象生成与释放的细节而更加关注于实体的工作。所以就像对象的封装性一样，JAVA同样希望籍以封装对象在内存中的一些底层实现而方便大多数的程序员。
    但同时我也需要更正自己先前的言论，就是无论JVM在底层的封装性上做得多么完备都无法解决许多特殊的内存释放情况，所以在此你可以调用诸如xxx.close()函数（某些对象有的话，比如File,Connection,Statment对象），并将其至于try-catch-finally块中加以强行调用。
    但是最后我们还是得明白，对对象底层的操作确实不是诸如JAVA、C#之类的面向对象的语言所要关注的重点，所以除了异常等可能导致内存隐秘泄露的场所，在大多数情况下他们并不会被特别关注。@.@||~

Answer 8

好，概然 midthinker(呵呵) 说手动释放对象是很多隐蔽错误的极大根源!    我再想问一下大家对于File,Connection,Statment这些对象，在某个类（classA）是使用了这些类，并且这些类定义为private(或类中所有方法都可使用的形式)，是不是要为这些对象增加一个关闭的方法(暂名为close吧)？
    在另一段代码使用了classA,在classA不使用的时候，我们必须得调用classA.close()吧？如果我们忘记了调用classA.close()呢？会造成什么后果？
    如果java提供了手工释放，我们就会省了多写一个close().就算我们忘记了手工释放也有自动释放顶上。我觉得这种模式对程序员来说省了不少事。

Answer 9

TO AiQun(爱麇):
    ...那如果阁下忘了调用close() method 呢？
    C++群体中有一个笑话，那就是“是的，我已经在所有该关闭他们的地方，做了稀释”，可糟糕的是在一个并不算大的中小型项目中，忘记在必要时刻调用释放函数都是稀疏平常的事（这就是我说的手动释放对象是许多隐蔽错误的根源），原因是我们编写的是应用域的代码，但稀释则属于解决域的特殊问题，我们当然更加关注于真正需要解决的问题，并由于我们不是万能的上帝而遗漏了许多东西，fire fox的创始人说，如果要吹毛求疵，世界上恐怕只有Hello world才可能没有BUG。
    JAVA 从创始开始的一个理念就是要提高程序员的编程效率以及尽可能的自动化降低错误的产生，少写一个CLOSE，多写一个CLOSE，不过是2秒钟的事情，但手工释放对象为此遗留的隐患却可能导致在测试与维护周期中投入大量人力、物力与时间成本（却仅仅是因为几个内存泄露问题），你可以想象在100行代码中找出一个这样的问题已经让你有点感觉麻烦了，更不要说有3、4层结构，7、8个子系统，几十个类组成的类库，以及成千上万行的代码中去找寻一个对象释放问题，如果您有兴趣到可以尝试一下，我想这样您就能明白节省时间成本的概念不是在代码编写过程，而恰恰是在测试与维护的过程中了，呵呵。@.@||~

Answer 10

同意midthinker(呵呵)所说，鱼与熊掌并不总是可以兼得，Java既然把安全性和开发效率放在重要的位置上，那么可能就不得不把其它一些别的因素放在次要的位置上。
毕竟，内存不够了，才几毛钱一兆，而通常对于一个项目，开发人员能够节省哪怕一天的时间，这笔钱就省出来了。你可以算算一个小组如果每一个项目都能省一天，一年做这样的3个项目，省下来的员工薪水可以买多少内存。更何况，Java所带来的开发效率的提升对于特别是企业级的项目来说，所节省的时间还不止一天，而且所节省的也远远不只开发期的成本。
当然，最终要看项目的性质，也又好多场合不适合用Java开发，比如单片机、3D引擎等等。那也是因为在这些场合，资源效率对效益的影响远大于开发效率。
那么再又一些需要，本身极其接近底层，无法要求产品的用户都必须先装JVM，或者根本不现实，比如磁盘的驱动，那就更不能采用Java开发了。

Answer 11

System.gc();是建议开始回收，但是不是绝对就运行