高手们来讨论一下吧：有关java的垃圾回收

Question

有一本“Java2程序设计（王克宏）”讲的挺不错的。
可以使用Java2提供的HotSpot编译器。
从某种方面讲，使用现代的垃圾收集技术，反而会大大提高效率，程序性能会比显示释放有明显提高。
HotSpot使用一次性拷贝回收收集，提高速度，降低可感知的暂停
如果需要，HotSpot可压缩长时间不使用的对象。
HotSpot提供增量收集的方法。把原来需要暂停的时间分成许多非常短的片断（通常少于十万分之一秒）。
HotSpot提供精确的回收技术，所有对象可以重新定位，因而可以实现内存对象压缩。

Answer 1

感谢任兄高见，再次我又有几个问题：1）HotSpot编译器是sun公司授权的标准编译器吗？2）您有没有HotSpot编译器对性能提高的比较资料吗？3）这只是对java的系统级的提高方案，有没有开发人员主动控制的方法？

Answer 2

有的 JVM 可以选择异步的线程来处理垃圾回收，即不需要暂停其它线程的运行。
HotSpot 不是免费可使用的优化技术，Sun 只是在它自己的 NT 和 Solaris 上的 JVM 中使用了它。如果其它 OS 厂商要使用则需支付专利费用(Sun 也是从其它厂商处并购到这项技术的)。所以 AIX/HPUX 等其它厂商有各自的优化技术。例如 Symantec 有自己的优化技术，IBM 的 JDK 的性能是最好的(也用了独有的技术)。
在 Java 编程中不建议让开发人员负责内存的管理。想想 NT 的虚拟内存交换技术，很类似的架构想法，运行环境更能了解整体的资源使用从而获得更为高效的运行结果。

Answer 3

用System.gc()可以使JVM进行一次垃圾收集,当System.gc()返回时JVM会尽最大努力收集无用的内存空间.但如果无用的空间过大,哪收集的时间会不会过长呢?这个问题我想是和你所使用的VM有关的,因为我对比过IBM和sun的JVM,发现SUN的jvm占用资源较小,回收垃圾也比IBM的快.

Answer 4

jatom兄现在的问题是：假如调用System.gc()进行垃圾回收，将阻塞其他线程，对于实时性强的系统，这样会不会带来损失？还是我的理解有错，只是将访问系统内存的线程挂起？？simon兄你看会不会出现这种现象：各编译器及JVM的不统一会不会造成java阵营的分化？对了，有谁能对我看到的那个现象做个解释？？谢谢！

Answer 5

好象还有一个Runtime.gc()也可以进行垃圾回收，和System.gc()有什么区别呢？

Answer 6

QDog兄,请注意是"尽最大努力",也就是说JVM会根据程序运行的情况来决定是否运行垃圾回收.而你所指的"实时性强的系统"是属于哪一方面呢?(基于Web,应用程序)
TO radish
  Runtime.gc()与System.gc()一样,只不过用System.gc()比较方便

Answer 7

QDog兄,请注意是"尽最大努力",也就是说JVM会根据程序运行的情况来决定是否运行垃圾回收.而你所指的"实时性强的系统"是属于哪一方面呢?(基于Web,应用程序)
TO radish
  Runtime.gc()与System.gc()一样,只不过用System.gc()比较方便

Answer 8

嗯，我说的"实时性强的系统"是指这样的系统：不仅仅只从界面接收用户信息，可能有多种渠道，而且有些信息必须及时相应的情况。比如说，基于applaciation的网络管理系统的客户端平台，这种平台除了需要处理用户界面上接受的用户信息外，还要处理服务器端的各种告警信息，并对重大告警信息及时做出相应。此时的垃圾回收会不会带来严重的问题？若是的话，问题又来啦：什么时候我们才能使用System.gc()进行垃圾回收？？

Answer 9

thread和gc本来就平台相关的，各操作系统上jvm的实现肯定会不一样。

Answer 10

JVM 也有规范要遵循对运行在其之上的程序而言是统一的。
其实我觉得对你而言如果 JVM 不那么及时的作 gc，更能满足您的要求。这是程序执行效率和所占资源的一个折衷。

Answer 11

JVM 也确实有规范也要求其之上的程序统一的，但thread和gc两个例外。比如线程优先级不可能一致，因为它和操作系统相关，windows和solaris的实现就不一样。要想研究java深层问题，必需好好看看 jls和jvms，这两个规范有中文版北大翻译的，不过出的比较早现在可能找不到了。

Answer 12

以下摘自jvms
To implement the Java virtual machine correctly, you need only be able to read 
the class file format and correctly perform the operations specified therein. Implementation details that are not part of the Java virtual machine's specification would unnecessarily constrain the creativity of implementors. For example, the memory layout of run-time data areas, the garbage-collection algorithm used, and any internal optimization of the Java virtual machine instructions (for example, translating them into machine code) are left to the
discretion of the implementor. 

Answer 13

使用softref手动控制GC，不过比较另类。

Answer 14

我觉得gc并不会出现平台相关的问题，因为gc主要是对存储器的操作，各操作系统在对内存的操作的差异并不像文件系统之间的差异那么大（个人意见），大家认为呢？有谁知道：垃圾回收是在什么样的时机下发生（以windows平台为例）？如果我们调用System.gc()，是否系统立即执行回收，还是等待某个时机的到来？softref是个什么好东西呀？rypan兄能否介绍一下？？有谁知道哪里有介绍jvm的书籍呀（中、英文都可以）？我跑遍了书市也没找到一个！我觉得java要是同时提供收动和自动两种垃圾回收方式就好啦！

Answer 15

java.sun.com/docs有你要的资料.
不过建议你不要手工控制GC, 使用Java就要付出代价, 如果内存不够大的话
当初就不应该选择Java. 即便是你找到了控制GC的办法, 真的要用好也是不
容易的. 就连C++现在也正在慢慢地淘汰delete的使用.

Answer 16

thread 和 gc 的实现与 JVM 的平台非常有关系，JVM 部分依赖于其运行平台的操作系统来实现这些功能。对 Thread 而言，你的执行结果可能不同(多线程编程)。而对 gc 而言，对你应该是透明的。