IBM JDK和sun jdk区别

在IBM的虚拟机官方指导文档中明确指出，禁止将虚拟机的最大值和最小值设置为相等，否则会导致以下2个后果

<1>极大的增加垃圾回收时间，影响系统性能

<2>造成系统中存在内存碎片。

然而，BEA推荐将最小堆大小和最大堆大小设置为同一值，因为这样可以避免浪费用于时常调整堆大小所需的 VM 资源。

同样是堆大小，却有两种不同的说法，有必要来分析一下。

先看IBM的文章摘录：

IBM的虚拟机官方指导文档

Initial and maximum heap sizes

When you have established the maximum heap size that you need, you might want to set the minimum heap size to the same value; for example, -Xms 512M -Xmx 512M. Using the same values is not usually a good idea, because it delays the start of garbage collection until the heap is full. The first time that the Garbage Collector runs, therefore, becomes a very expensive operation. Also, the heap is most likely to be very fragmented when a need to do a heap compaction occurs. Again, this is a very expensive operation. The recommendation is to start your application with the minimum heap size that it needs. When it starts up, the Garbage Collector will run often and, because the heap is small, efficiently.

The Garbage Collector takes these steps:

If the Garbage Collector finds enough garbage, it exits.

If it cannot find enough garbage, it goes to the next step.

The Garbage Collector runs compaction.

If it cannot find enough garbage, it goes to the next step.

The Garbage collector expands the heap.

Therefore, an application normally runs until the heap is full. Then, successive garbage collection cycles recover garbage. When the heap is full of reachable objects, the Garbage Collector compacts the heap. If and when the heap is full of reachable objects and cannot be compacted, the Garbage Collector expands the heap size.

From the above description, you can see that the Garbage Collector compacts the heap as the needs of the application rise, so that as the heap expands, it expands with a set of compacted objects in the bottom of the original heap. This is an efficient way to manage the heap, because compaction runs on the smallest-possible heap size at the time that compaction is found to be necessary.

Compaction is performed with the minimum heap sizes as the heap grows. Some evidence exists that an application’s initial set of objects tends to be the key or root set, so that compacting them early frees the remainder of the heap for more short-lived objects.

Eventually, the JVM has the heap at maximum size with all long-lived objects compacted at the bottom of the heap. The compaction occurred when compaction was in its least expensive phase. The overheads of expanding the heap are almost trivial compared to the cost of collecting and compacting a very large fragmented heap.

文档里写到，设置-Xms和-Xmx一样大会耽误垃圾回收的开始直到堆满，这样第一次垃圾回收就会变成非常昂贵的操作。推荐把-Xms设置为应用所需的最小值，这样会产生高效的垃圾回收。

关于垃圾收集器：

1 如果找到足够的垃圾， 这些垃圾释放后的空间够用 那么就不进行压缩。

2 如果找到的足够的垃圾，但这些垃圾释放后空间不够用，那就进行压缩。

3 如果找到的垃圾不够多， 即使压缩后的空间也不够用 那么进行堆扩展。

之所以两种虚拟机的设置的方法存在冲突，主要是因为垃圾回收机制的不同。

Sun: GC策略默认是复制、分代算法。也就是说，它会将heap分成不同的几个区，譬如Solaris JVM中最上面有两个大小相等的区。GC时刻，将一个区的存活对象复制到另外一个对等区，垃圾对象就算遗弃了。这样在heap里面，就不存在碎片问题。

IBM: 默认GC策略并没有采取复制、分代方式，而是采用了标记-清除-压缩的方式。并且，它不像Sun的JVM那样，有个单独的方法区，它的方法区就放在Java堆空间里面。

前面提到过：IBM禁止将虚拟机的最大值和最小值设置为相等是因为会极大的增加垃圾回收时间。那难道Sun的虚拟机就不会造成垃圾时间过长吗？

是因为Sun的虚拟机的垃圾回收方式是分代收集，分代收集本身是并发的，是多线程同时进行，而且一般minor gc的时间很短，只有major gc的时间可能比较长 但是major gc 发生在tunured空间 这个空间大小一般也就是堆的一半。所以呢，Sun虚拟机可以将-Xms和-Xmx设置为一样大小以节约堆延伸和收缩所需的资源。

IBM虚拟机之所以不设置为一样大小，除了怕影响垃圾回收的效率（要在当前堆耗尽，也就是遇到AF才会GC，如果初始值和最大值一样，那么很久才会进行，而且第一次GC就是大范围的）。除了这个原因，如果堆是从很小慢慢进行扩展的话，那么后来扩展的堆在进行压缩的时候 ，是不需要对前面已经压缩的堆进行过多操作的，换句话说，如果是初始堆很大的话 那么以后每次压缩的时间都会很长。

 出处：http://www.tonyxu.net/java/201003129/ibm-sun-jdk.html