概述：
JVM性能调优没有一个非常固定的设置，比如堆大小设置多少，老年代设置多少。而是要根据实际的应用程序的系统需求，实际的活跃内存等确定。
正文：
JVM调优工作流程
整个调优过程是不断重复的一个迭代，后面的步骤有可能影响前面的配置，可能需要重新调优。
应用程序的系统需求
确定应用程序的系统需求是性能调优的基础，后面的调优都会依赖这个要求。一个应用不会无休止地调优下去。
1.可用性
2.可管理性
3.启动时间
4.吞吐量
TPS: 每秒多少次事务
QPS: 每秒多少次查询
5.延迟
比如关键请求必须60ms完成响应
6.内存占用
选择JVM的部署模式
单JVM部署模式：可以用更多的物理内存
多JVM部署模式：减少了单点，不过分布式部署也解决了这个问题
JVM运行模式
32位JVM：
内存空间限制为4G，关键是还进一步受限于操作系统，Windows大约1.5G，Linux大约3G。
64位JVM：
对象指针的长度从32位变为64位，导致CPU高速缓存可以缓存的指针变少，降低了缓存效率。可以开启指针压缩，解决这个问题，指针压缩在堆小于等于26GB时，性能最好。JVM会根据堆大小自动开启这个。
垃圾收集调优基础
基本原则
1. 每次MinorGC都尽可能多地收集垃圾对象。可以减少FullGC的频率，因为FullGC的持续时间总是最长；
2. 处理吞吐量和延迟问题时，GC能使用的内存越大，垃圾收集的效果越好，应用越流畅；
3. 在这三个属性（吞吐量、延迟、内存占用）中任意选择两个进行JVM垃圾收集器调优，因为三个属性肯定不能同时满足；
GC日志
GC日志是收集调优所需信息的最好途径，下面是一次MinorGC的日志，FullGC的日志和这个类似：
5.483: [GC (Allocation Failure) [PSYoungGen: 142650K->16873K(145408K)] 168504K->48298K(189440K), 0.0769590 secs] [Times: user=0.22 sys=0.00, real=0.08 secs]
1). 各属性说明
5.483：是JVM启动到现在的时间戳
Allocation Failure：Eden区分配内存失败，导致GC
142650K（新生代回收前大小）->16873K（新生代回收后大小）（145408K（新生代总大小））
168504K（回收前堆占用大小）->48298K（回收后堆占用大小）（189440K（堆总大小））
Times：user（GC非操作系统指令占用的CPU时间）sys（GC操作系统调用占用的CPU时间）real（实际占用的CPU时间）
2). 计算老年代方法
根据上面这个MinorGC日志，可以推算出老年代在GC前后的大小。
GC前：168504K（回收前堆占用大小）-142650K（新生代回收前大小）=25854K
GC后：48298K（回收后堆占用大小）-16873K（新生代回收后大小）=31425K
3). GC日志命令行选项
|
-XX:+PrintGCTimeStamps |
打印此次垃圾回收距离jvm开始运行的所耗时间 |
|
-XX:+PrintGCDeatils |
打印垃圾回收的细节信息 |
|
-Xloggc:<filename> |
将垃圾回收信息输出到指定文件 |
|
-XX:+PrintGCDateStamps |
需要打印日历形式的时间戳选项 |
|
-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime |
打印应用程序由于执行VM安全点操作而阻塞的时间以及两个安全点操作之间应用程序的运行时间 |
|
-XX:+PrintSafepointStatistics |
可以将垃圾回收的安全点与其他的安全点区分开 |