前言
此篇文章是关于Userful JVM Flags系列2和系列4的总结
JVM flag类别
- 标准flags，标准flags一般都是最基本的flags，而且在将来JVM的发布版本中基本不会改变的，例如-server -client
- X flags，这类的特点是非标准，随着JVM版本不同可能会改变；这类flags都是以-X开头，通过java -X可以列出所有(少了-Xcomp)
- XX flags，这类也是非标准的。Xflags很稳定，XXflags可能更加实验性(主要被JVM开发者用于debug和优化JVM实现)。在使用X flags或者XX flags之前一定要明白flag的使用方式和可能带来的副作用。XX flags都以-XX开头，但是语法根据flag type不同而不同
XXflags使用方式
- 如果是boolean flag,使用+ -。例如<b>-XX:+<name></b> activate <b><name></b>,-号表明deactives that option.
- 对于非boolean flag，使用-XX：<name>=<value>的方式
关于堆调整(Heap Tuning)的Flags
以下的讨论的heap是这样的heap（堆）：基于经典分类，分为young gen, old gen , permanent gen 。1.8已经没有permanent gen，不在该讨论范围
-Xms and -Xmx(or: -XX:InitialHeapSize and -XX:MaxHeapSize)
-Xms和-Xms是目前最流行的JVM flags，用来指定初始heap大小和最大heap大小
一般用k表示kilo，m表示mega，g表示giga，例如
<pre>java -Xms128m -Xmx2g myapp</pre>表示myapp应用堆初始化大小为128m bytes，最大为2g bytes。
主要注意的是-Xms -Xmx相当于对应-XX的别名，当我们使用-XX:+PrintCommandLineFlags时，需要搜索InitialHeapSize和MaxHeapSize，而不是Xms和Xmx
-XX:+HeapDumpOnOutOfMemoryError ,-XX:HeapDumpPath=<path>
当我们系统发生OOM错误的时候，通过我们需要jmap heap dump，但是有可能虚拟机已经crash了的时候，我们最好设置-XX:+HeapDumpOnOutOfMemoryError，这样在发生OOM的时候回自动heap dump,由于通常heap dump文件都很大，所有最好是指定path
-XX:OnOutOfMemoryError
当我们需要在发生OOM的时候执行一些脚本或命令，我们可以通过该flag指定
<pre>$ java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -XX:OnOutOfMemoryError ="sh ~/cleanup.sh" MyApp</pre>
-XX:PermSize and -XX:MaxPermSize
可以使用-XX：PermSize指定初始化Permanent大小，使用MaxPermSize指定最大大小
-XX:InitialCodeCacheSize and -XX:ReservedCodeCacheSize
一个经常被忽视的JVM内存区域是"code cache"，用来存储方法编译后的native code。平常该区域不会存在性能问题，但是一旦发生问题都是灾难性的。当code cache区域用尽时，JVM会给出警告信息然后切换到"interpreted-only "模式，该模式下停止JIT编译器，字节码不能编译成native code，性能急速下降。可以通过设置-XX:InitialCodeCacheSize
and -XX:ReservedCodeCacheSize来调整code cache区域大小
-XX:+UseCodeCacheFlushing
这个参数与code cache有关，当code cache持续增长时，发生overflow是迟早的事情，此时可以通过设置UseCodeCacheFlushing来避免最终切换到interpreted-only模式。从名字可以看出，用法就是当JVM code cache填满时会丢掉一些编译了的代码从而避免进入interpreted-only 模式。但是该种方法治标不治本，还是得找出根源修复内存泄露的问题。
