Java内存管理之基础概念——JVM运行参数的自动选择和行为调校
在J2SE 5.0以后，JVM会根据应用程序运行的硬件平台、操作系统自动选择不同的JVM运行参数和使用的垃圾收集器。JVM对“服务器”的定义需要满足以下几个条件：
- 2个以上（包含2个）的物理处理器
- 2G以上（包含2G）的物理内存
上面这个服务器的定义适用于所有的平台，但运行32位的windows操作系统例外。
JVM对不是“服务器”的运行环境提供的缺省JVM运行配置如下：
- 使用JVM客户端运行模式
- 使用串行收集器
- 初始堆大小是4MB
- 最大的堆大小是64MB
在服务器环境下JVM始终运行的是“JVM server”模式，除非在java 命令行中加入了-client 命令行参数。JVM对“服务器”的运行环境提供的缺省JVM运行配置如下：
- 使用JVM服务器运行模式
- 使用并行收集器
- 初始堆大小是1/64物理内存（由于JVM要求服务器最少2G内存，所以1/64物理内存的最小值是32M）
- Heap最大值是1/4的物理内存，1G封顶
JVM提供的这些缺省值都是通过java的命令行参数加以调整，这部分内容见以后的文章。
在J2SE 5.0以后，JVM提供了一些选项用来调整并行垃圾收集器的最大停滞时间（maximum pause time）和应用程序的吞吐量。
最大停滞时间
-XX:MaxGCPauseMillis=n（单位是毫秒）
这个参数顾名思义就是要求并行收集器的停滞时间小于等于指定的毫秒数。并行收集器会调整堆的大小和其他一些跟垃圾回收相关的参数以最大程度的满足这个最大停滞时间的限制。但这些调整可能导致应用程序吞吐量的下降，而且在某些情况下这个最大停滞时间也不能够得到满足。控制最大停滞时间这个目标会分别运用到各个代上，如果目标无法实现，每个代的大小都会被缩小以满足最大停滞时间这个目标。最大停滞时间这个参数没有缺省值。
吞吐量
吞吐量是通过花在GC上的时间和应用程序运行上的时间做比较计算得到的。
-XX:GCTimeRatio=n
这个参数的意思是要求GC时间和应用程序运行时间之间的比例满足1/(1+n)
例如-XX:GCTimeRatio=19 意味着GC的时间只能是全部时间的5%。吞吐量参数的缺省值n=99。如果达不到这个数值的话，JVM就会设法增加代的大小以保证应用程序在GC回收之间有更多的时间可以用来运行，原因很简单代越大的话，被填满的时间也需要越长。
如果最大停滞时间和吞吐量这两个目标都已经被满足了，GC就会减少heap的大小，直到其中的一个目标不能被满足（其实就是吞吐量这个目标）。最大停滞时间和吞吐量这两个目标存在着优先级的差别，最大停滞时间的优先级高于吞吐量，也就是说GC会先满足最大停滞时间这个目标，然后采取满足吞吐量这个目标。
借助JVM的自动选择功能，我们可以最初先不对应用程序的JVM做什么配置，通过运行和测试，如果发现系统有比较好的吞吐量而停滞时间也比较短暂的话，我们就不需要调整什么GC的选项。如果证明存在着跟GC相关的性能问题，然后再对GC的选项加以调整。过程中可以利用一些性能分析和测量的工具。
选择不同的垃圾回收器
–XX:+UseSerialGC
–XX:+UseParallelGC
–XX:+UseParallelOldGC
–XX:+UseConcMarkSweepGC
调整堆（HEAP）大小
如果应用程序出现了OutofMemory的问题，也就意味着JVM的某个代或者整个堆的大小存在问题，需要加以调整，但有点矛盾的地方时堆开的越大，应用程序的停滞时间就会越长，所以我们在满足停滞时间方面没有问题的话，我们就可以尽可能的提升堆的大小。除了调整Heap的大小，还可以对调整不同代的大小，代的大小也是影响GC性能的重要因素。除非发现了过度的老生代的回收或者停顿时间，否则尽量新生代的大小尽量大。如果使用的是串行收集器，新生代的大小不要超过老生代的一半。如果使用的是并行回收器，最好对JVM的行为加以调整而不是直接调整堆或者代的大小，而让收集器跟据我们设定的目标自动去调整相关的参数。如果堆的增长超过了最大值，绝大多数情况下，这意味着在这个最大堆大小的限制下吞吐量的目标很难实现，将最大值设置设置成接近物理内存（但是不要引起应用程序的Swaping），如果吞吐量还是无法实现的话，就要考虑一下再当前平台可用内存的情况下，这个吞吐量的目标是不是过于苛刻了？
如果吞吐量目标得到了满足，但导致停滞时间太长了话，选择一个最大停滞时间目标。选择的最大停滞时间又可能导致吞吐量的目标无法实现，所以需要在这两个目标之间做妥协。
