JVM 调优不像读脚本一样，它更像是在一群性格各异、有点吵的员工中间做决策。
不要指望把 JVM 调优当成一本操作手册来照着念，那玩意儿忒死板，也不够真。咱们得先明白，JVM 处理数据有没完没了，有时候数据量大到能装下一个镇子；有时候那数据又小得连蚂蚁都不足以承载。 要是数据量小，内存池（Heap）就显得有点大了，这时候要是堆里的东西忒多，程序运行起来就会变慢。出于线程忒多了，CPU 得围着它们转，还得时不时去“抹墙”（GC），这就相当于你在广场上种了忒多树，风一吹，树叶子一落，空气（垃圾）就满屋子了。
这时候你能够加堆，但这玩意儿效果也就那样，根本解决不了核心难题。 反过来，要是堆里的东西又忒少，那程序就得拼命干活。CPU 被占满了，线程都在假忙，CPU 得频繁地上下浮动（上下文切换），这速度自然慢。
这时候你该上堆，把空间填满了，CPU 就不忙了，速度就快了。 故此，神马堆忒大，神马堆忒小，都是难题。真正的调优，得看那堆里的东西到底长啥样。 举个例子，咱们看一个典型的场景。假设你的程序形成了 100 兆的数据，堆初始配置 4G，每代 1G，GC 是标记收集 GC。初始状态，CPU 跑得像夸克一样快，出于内存池得 100%，CPU 根本别想去查看线程列表。
这时候要是一点如何调？涨了，内存池 8G，每代 2G，GC 还是标记收集。
这时候 CPU 反而变慢了，出于数据多了，GC 还没跟上，CPU 就忙不过来了。 这时候就该想想，是不是真有难题。
要是数据是缓存，那肯定是缓存没预热；要是是数据库查询，那就是数据库慢。
要是堆里的程序代码本身写得烂，那只能优化代码，而不是调参数。 那到底该如何调？别一上来就调参数。先看看 GC 日志。
要是 GC 工夫占比特别高，那肯定是参数没调对，要么数据有难题。
这时候能够调参数，比如调 g1 保留工夫，要么调标记清除的周期。但这事儿得看具体业务。 再比如，一个电商系统，日活用户多了，G1GC 的保留工夫调低了，GC 频率高了。
这时候要是突然加了个新的大功能模块，害得堆里的数据瞬间膨胀 50%，这时候 GC 频率更低，但响应更慢。
这时候是不是该调参数？
是不是该加堆？
是不是该优化代码？答案可能都不是。
这时候你得看 GC 日志，看看是哪种垃圾被回收了。
要是是对象引用，那说明数据有难题。
要是是引用计数，那说明对象不好设计。
这时候就得改代码，而不是调参数。 这就是调优的精髓：别盲目调参数。先搞清楚数据长啥样，再分析 GC 日志，看是哪类垃圾在捣乱。
要是数据没难题，那再寻思参数。
这时候你能够调偏向收集，要么调标记清除的间隔。
要是参数调了还是不中，那可能是代码写得烂。
这时候你得去查代码，找瓶颈，优化算法。 故此，调优一辈子不是调参数的事。调优是分析、是观察、是思索。你得像侦探一样，看日志，看数据，看代码。
有时候数据真不中，有时候代码写得真烂。
有时候是参数没调对，有时候又是系统架构设计的难题。 最终，调优不是一蹴而就的。你调了参数，上线后效果没变，那说明难题不在参数，而在数据要么代码。
这时候你得重调参数，就连重调架构。
故此，别急着给 JVM 加参数，先看看那堆里的东西到底长啥样。调优是门艺术，也是门科学，得结合实际情况，才能把程序调快。
