作者：林昊
前几年在将OS从32 bit升级到64 bit，以及虚拟机的内存调整到8G后，我把应用的Java启动参数重新写了一版，作为目前大部分Java应用的默认启动参数模版，这几年下来，发现在这个标准版的启动参数上还是犯了一些错误的。
1. -XX:+DisableExplicitGC
Java在实现RMI Server的时候会通过定时的调System.gc来强制做GC（即使程序里没用到RMI也会被启动），这个动作非常烦人，另外也是为了避免应用代码上显式去调用System.gc导致一些没必要的GC动作产生，所以当时就直接加上了这个参数。
现在来看，这个参数有个挺大的问题是，Direct ByteBuffer所占用的内存以及FileChannel.map所占用的内存当达到了他们的最大阈值时，需要依赖调用System.gc来强制释放下，如果加上了这个启动参数，就意味着这个强制的释放就无效了，这会导致的一个问题是，当old gen还没到达触发full gc/cms gc的条件，而堆外的Direct ByteBuffer/FileChannel.map占用的空间又超过了它们的最大阈值时，就会直接导致OOM，而这种情况下很有可能其实是可以借助显式调用System.gc来释放出足够的空间，不过话说我仍然觉得这是JDK设计上应该改进的一点，不应该在这个时候需要依赖System.gc来管理堆外的空间，大家可以翻下FileChannel.map的代码就会发现那里在等待System.gc执行的结果是写S的等待100ms，事实上很少有full gc/cms gc可以在100ms完成。
不过鉴于上面的状况，如果应用里有使用到不少Direct ByteBuffer或FileChannel.map的话，建议还是不要开启-XX:+DisableExplicitGC，如果是cms gc的，还是改为加上这个参数-XX:+ExplicitGCInvokesConcurrent，另外如果有RMI Server这种定时GC影响的，再调整下-Dsun.rmi.dgc.client.gcInterval和-Dsun.rmi.dgc.server.gcInterval这两个时间吧，时间单位是ms，也可以设置为Long.MAX_VALUE。
2. 缺少-XX:+UseCMSInitiatingOccupancyOnly
由于我们的Java应用的heap基本都是大于4G的，所以都是用的CMS，当时我在写启动参数的时候一直犹豫要不要加上-XX:+UseCMSInitiatingOccupancyOnly这个参数，一犹豫就没加，但事实上后来碰到了不少应用由于JVM自行触发CMS GC的机制导致CMS GC频繁，所以建议用CMS GC的场景下还是加上这个参数更稳妥。
3. -XX:MaxDirectMemorySize
话说在写启动参数的时候我都压根不知道这参数（要知道Java到底有哪些启动参数可用，以及默认值是多少，最靠谱的方法是在启动参数上加-XX:+PrintFlagsFinal或用jinfo -flags [pid]来查看），后来是由于有一次出现了有应用物理内存被耗光，排查的时候才发现是Direct ByteBuffer这块默认的大小是heap size，所以在有些情况下可能会出现Direct ByteBuffer这里占用了大量的空间，但heap这边又还不到触发Full gc/CMS gc的条件，就会有可能导致物理内存被耗光。
因此对于远程交互比较多的应用，建议还是加上这个参数，合理控制大小，不要让heap size+Direct Memory Size就把物理内存给耗光了。
ps: 关于Java常见问题的排查方法，重新专门写了一个PPT，涵盖了以下几种常见的Java问题的排查方法：
1. 类加载问题，例如NoSuchMethodException；
2. 内存问题，例如各种OOM；
3. 应用无响应问题，例如http访问后返回499；
4. CPU利用率问题，例如us耗尽；
5. Java进程退出问题。
