JVM调优Demo（一）避免新生代过小（增大新生代大小）

来源：互联网发布：jdbc 删除数据编辑：程序博客网时间：2024/04/28 19:03

先上代码：

主函数：

public class GCDemo {public static void main(String[] args) throws InterruptedException{List<GCDataObject> list = new ArrayList<GCDataObject>();for(int i = 0 ; i < 4 ; i++){list.add(new GCDataObject(2));}//表示第二次fullGC，或者MinorGC可以把他回收！list = null;List<GCDataObject> list2 = new ArrayList<GCDataObject>();for(int i = 0 ; i < 3 ; i++){list2.add(new GCDataObject(2));}list2 = null;}}

对象（好像直接内部类不好~）：

public class GCDataObject {byte[] bytes = null;public GCDataObject(int i){bytes = new byte[i *1024 * 1024];}}

为调优的前的参数：

-Xms20M -Xmx20M -Xmn10M -verbose:gc -XX:+PrintGCDetails -XX:+UseSerialGC

打印的日志：

[GC (Allocation Failure) [DefNew: 7299K->524K(9216K), 0.0033509 secs] 7299K->6668K(19456K), 0.0033976 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] [GC (Allocation Failure) [DefNew: 6826K->6826K(9216K), 0.0000107 secs][Tenured: 6144K->4618K(10240K), 0.0025299 secs] 12970K->4618K(19456K), [Metaspace: 2576K->2576K(1056768K)], 0.0025761 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] Heap def new generation   total 9216K, used 2130K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)  eden space 8192K,  26% used [0x00000000fec00000, 0x00000000fee14930, 0x00000000ff400000)  from space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)  to   space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000) tenured generation   total 10240K, used 4618K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)   the space 10240K,  45% used [0x00000000ff600000, 0x00000000ffa82990, 0x00000000ffa82a00, 0x0000000100000000) Metaspace       used 2582K, capacity 4486K, committed 4864K, reserved 1056768K  class space    used 287K, capacity 386K, committed 512K, reserved 1048576K

大致的过程：

首先向虚拟机分配的4个2M的对象，当中因为参数的设置，新生代Eden为8M，两个Survivor为1M，中间发生了1次MinorGC，是以Eden空间不足导致，而且都是立马从Survivor再次发生MinorGC进入到了旧生代，第一次FullGC清理掉了之前的8M，此时内存分配情况为新生代的Eden为2M（有误差），旧生代为4M，

解决方法：

因为FullGC非常的耗时，需要尽量减少它的次数。但是又不得不MinorGC，所以加大年轻代的空间，在撑到第一个集合的对象分配完后，在下一次分配集合后发生MinonrGC就把之前的对象回收掉。

同样利用上面的代码（业务逻辑不变），修改的参数为：

-Xms20M -Xmx20M -Xmn16M -verbose:gc -XX:+PrintGCDetails -XX:+UseSerialGC

运行日志：

[GC (Allocation Failure) [DefNew: 11615K->523K(14784K), 0.0026278 secs] 11615K->2571K(18880K), 0.0026997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] Heap def new generation   total 14784K, used 5006K [0x00000000fec00000, 0x00000000ffc00000, 0x00000000ffc00000)  eden space 13184K,  34% used [0x00000000fec00000, 0x00000000ff060bc0, 0x00000000ff8e0000)  from space 1600K,  32% used [0x00000000ffa70000, 0x00000000ffaf2f20, 0x00000000ffc00000)  to   space 1600K,   0% used [0x00000000ff8e0000, 0x00000000ff8e0000, 0x00000000ffa70000) tenured generation   total 4096K, used 2048K [0x00000000ffc00000, 0x0000000100000000, 0x0000000100000000)   the space 4096K,  50% used [0x00000000ffc00000, 0x00000000ffe00010, 0x00000000ffe00200, 0x0000000100000000) Metaspace       used 2582K, capacity 4486K, committed 4864K, reserved 1056768K  class space    used 287K, capacity 386K, committed 512K, reserved 1048576K

从之前的一次MinorGC和一次FullGC减少为一次MinorGC。

大致过程：

因为调整了年轻代大小，为16M，Eden为12.8M，Survivor为1.6M，第一次的集合分配，整整8M分配进了Eden，在下次集合的分配的时候，触发了MinorGC，回收掉了之前的8M对象，此时年轻代为4M，老年代为2M，Survivor里面不知道是什么东西。。。。。。

0 0