月度归档： 2015年7月

原文在 http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html ，下面是个人的一些理解，可能有不对的地方。

• 在启动参数中加上 -verbose:gc 可以打印出每次GC释放的空间以及耗时。
• JVM GC相关参数：

• -XX:MinHeapFreeRatio=<minimum>  -XX:MaxHeapFreeRatio=<maximum>   -Xms<min>  -Xmx<max> 当某一代的内存超出了Min/MaxHeapFreeRatio的比例时(默认为40%-70%)，JVM会自动伸缩该代内存大小以确保在指定比例范围内，但自动伸缩不会超出该代允许的内存大小范围。由于系统默认的-Xmx和-Xmx都比较小，对于服务器程序，强烈建议启动时指明-Xms和-Xmx的值，并且这两个值相等，这样可以避免程序自己决定内存大小带来的开销，当然，如果这个值设置得不合适，JVM就无能为力了。
• – XX:NewRatio=<3> 指定新生代和年老代在堆内存中的比例(1:3)，即新生代占总heap区的1/4。 NewSize 和 MaxNewSize 可用来指定新生代的实际内存大小。
• -XX:SurvivorRatio=<6> 指定eden区和每个survivor区的比例(1:6)，即每个survivor占新生代的1/8(这里感觉有点奇怪，感觉应该是survivor比eden=1:6，但是官方文档这么说： sets the ratio between eden and a survivor space to 1:6 )。一般来说，调节这个参数对性能调优不是太重要。如果survivor区太小，GC时不够用来装来自eden区的live对象，那么这些对象会直接溢出到年老代，如果这个区太大，那么将会浪费掉一部分内存。

垃圾回收器的类别：

• serial collector 使用单线程来完成GC操作。由于不涉及到线程之间的通信，所以非常高效。如果只有一个CPU核心，或者程序使用的内存不会超过100M时，建议使用这种GC。这种GC不能有效利用多核，当系统只有单核CPU时，JVM会默认使用这类GC。估计现在已经很少见了。
• parallel collector ( throughput collector ) 在小GC时(新生代GC)，可以显著减少GC的开销。在多核或者多线程的硬件环境下，当应用使用的内存为中到大的规模时，应该使用这类GC。当系统有多核的时候，JVM会默认使用这种GC。默认情况下，这类GC仅在小GC时使用多线程，JDK6中，可以使用 -XX:+UseParallelOldGC 的参数来让FULL GC(Old区GC)也使用多线程。使用的线程数等于系统的核数，或者用- XX:ParallelGCThreads=<N> 来指定。由于GC时可能有部分对象从新生代移动到年老代，所以每个GC线程都会预留一定的年老代空间，这样可能会产生年老代碎片，减少GC线程数可以减少这种碎片化的影响，增大年老代空间。
• concurrent collector 通过牺牲应用性能来缩短GC时的服务停顿。使用 -XX:+UseConcMarkSweepGC 参数打开。

垃圾回收器的选择：

• 如果应用程序占用的内存不超过100M： -XX:+UseSerialGC
• 如果应用程序运行在单核服务器上并且对应用暂停服务没啥要求：  -XX:+UseSerialGC
• 如果应用程序的峰值处理能力最重要，并且对应用暂停服务一秒种或者更长时间可以接受：  -XX:+UseParallelGC  -XX:+UseParallelOldGC 此类情况多出现在后台跑的业务中，非用户交互的系统。
• 如果希望尽量缩短应用程序的暂停响应时间： -XX:+UseConcMarkSweepGC 此类情况较为常见，主要为涉及到用户交互的系统。由于可以通过多台服务负载均衡来弥补性能损失，而且可以保证服务不会在那里傻呆着几秒钟甚至几十秒钟来GC而没反应。

当使用并行GC时，JVM中内存分区和串行不同，如下图：

JVM的下一代G1垃圾回收器会逐渐取代传统的CMS垃圾回收器，但是JDK1.7.2目前还没有使用G1作为默认的垃圾回收器。G1的内存分布和上面的两种分布有非常大的不同，有兴趣的可以去看看。

系统的剩余可用内存空间可能会对垃圾回收性能产生严重影响。我有两台硬件完全相同的服务器，部署完全相同的应用，负载基本相同，但是垃圾回收的性能有本质差别，1台135次FULL GC耗时1分钟，另外一台82次FULL GC耗时34分钟。现在能找到比较明显的不同就是，一台剩余物理内存900M左右，另外一台剩余物理内存40M左右，不知道是不是由于这个原因造成了GC性能如此显著的区别。

近日在基于Netty写异步HttpClient的时候，需要等http连接建立并通道打开后，才能使用该连接来发送数据，但是Netty中只能等待到连接建立就会返回一个用来收发数据的channel，如果channel并没有打开，用来发送数据时就会报错，因此需要在代码中等到channel打开后再返回，想到了使用简单的wait&notify来解决，先上一段代码：

public class HttpClient{
    private Boolean connected = false;

    private final class InnerHandler extends SimpleChannelUpstreamHandler {
        @Override
        public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception {
            synchronized(connected){
                connected = true;
                channel = e.getChannel();
                logger.debug("{}",this);
                connected.notifyAll();
            }
            logger.debug("channelConnected");
        }
    }

    public void connect() throws Exception {
        ......InnerHandler hander = new InnerHandler();......
        ChannelFuture future = bootstrap.connect();
        future.await();

        synchronized(connected){
          if (future.isSuccess() && !connected) {
            logger.debug("connection opened,waiting for channel connected!");
            logger.debug("{}", hander);
            connected.wait();
          }
          logger.debug("new http client channel established!");
        }
    }
}

结果程序运行到connected.wait()便死锁了，经分析发现，connected.wait()和connected.notifyAll()进行操作的不是同一个对象，因为connected = true这里将connected 重新指向了另一个对象，代码上看来connected.notifyAll()没啥问题，其实这个信号已经没人收得到了，开始的那个connected.wait()也再也得不到任何信号，会一直等下去了。
修改代码，使用一个专门的对象来做锁：
private Object lockObject = new Object();
将synchronized、wait和notifyAll使用的对象都换为lockObject，一切正常。可见，使用对象锁的时候，尽量使用一个不会被潜在改变引用地址的对象做锁，最好专门新建一个Object来做锁。
当然只要保证synchronized、wait和notifyAll使用的是同一个对象，不专门弄个Object来做锁也是可以的，为了多搞点问题出来加深印象，将代码修改了一下：

public class HttpClient{
    private boolean connected = false;

    private final class InnerHandler extends SimpleChannelUpstreamHandler {
        @Override
        public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception {
            connected = true;
            channel = e.getChannel();
            synchronized(this){                
                logger.debug("notify:{}",this);
                notifyAll();
            }
            logger.debug("channelConnected");
        }
    }

    public void connect() throws Exception {
        ......InnerHandler hander = new InnerHandler();......
        ChannelFuture future = bootstrap.connect();
        future.await();

        if (future.isSuccess() && !connected) {
          logger.debug("connection opened,waiting for channel connected!");
          synchronized(hander){            
            logger.debug("wait:{}", hander);
            hander.wait();
          }
          logger.debug("new http client channel established!");
        }
    }
}

使用hander对象来做锁，这儿的代码已经确保大家使用的都是同一个hander，运行代码，发现一切正常，再运行几次，发现又死锁了，分析debug信息：
connection opened,waiting for channel connected!
notify: com.skymobi.http.HttpClient$InnerHandler@cc52fc
channelConnected
wait: com.skymobi.http.HttpClient$InnerHandler@cc52fc
原来程序执行时先跑去notify,然后再wait了,开始时不是很清楚为啥一定要加个synchronized，只是不加的话就不能用来wait，于是囫囵吞枣的加上个synchronized。这儿看来，加上synchronized应该是获取到锁，然后修改某些状态值，供别的线程根据这些状态值去判断是否需要做某些事情，一般synchronized中如果要使用wait，都需要先判断是否满足需要wait的条件，否则就会导致死锁，而在notify的synchronized代码片段中，一般会对判断条件使用的值进行修改，然后再通知wait的线程。
最后修改过能运行的代码如下：

public class HttpClient{
    private boolean connected = false;

    private final class InnerHandler extends SimpleChannelUpstreamHandler {
        @Override
        public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception {

            synchronized(this){          
                connected = true;
                channel = e.getChannel();      
                logger.debug("notify:{}",this);
                notifyAll();
            }
            logger.debug("channelConnected");
        }
    }

    public void connect() throws Exception {
        ......InnerHandler hander = new InnerHandler();......
        ChannelFuture future = bootstrap.connect();
        future.await();

        synchronized(hander){     
          if (future.isSuccess() && !connected) {
            logger.debug("connection opened,waiting for channel connected!");            
            logger.debug("wait:{}", hander);
            hander.wait();
          }
          logger.debug("new http client channel established!");
        }
    }
}