JVM调整--GC调优三选二原则

我们试着回答这样的问题：什么样的应用系统需要怎么样的JVM调整或是业务调整？

结算系统，是我们的内部管理系统，这个与其他面向终端用户的系统有哪些差异？对我们的系统有哪些要求？

1、批量操作是常态

      业管或是结算人员每天有一些批量数据处理的刚性需求。限制住条数，控制住数量需要和相关人员沟通合理的方式。

2、时效性有要求，但可以忍受

      内部管理系统与最终用户使用的系统主要区别就是对响应性的要求。延迟越大，用户流失相对越严重。

这也要求我们针对不同的系统特征，做出不同的JVM或是业务调整要求。

单单JVM调整来说。我们现在回到，我们需要多大的内存？

这个是持续跟进监控得出的数据（系统稳态跟踪计算得出）。

但总有一些建议的原则：比如，我们使用什么样的垃圾收集器？JAVA运行的程序，我们一般在吞吐量，响应性（延迟），内存占用做选择。

在对JVM垃圾回收，一般有三个原则

1、minorGC回收原则

     就是都希望短生命周期的对象都尽量在新生代被回收

2、GC内存最大化原则

     处理吞吐量与延迟问题时，垃圾处理器能使用的内存越大，即Java堆空间越大，垃圾搜集的效果越好，应用程序越流畅。

3、GC调优三选二原则

     在这三个性能属性（吞吐量，延迟，内存占用）选择两个调优。

另：现在我们业务框架使用springmvc+spring+hibernate+mybatis+....大量第三方框架，特别是对json，xml等数据处理jar包。再加上业务数据处理逻辑。

我们使用4G内存，大么？或是有天我们调整8G、16G、乃至32G内存，会感觉惊讶么？没有什么惊讶的！！！

系统伸缩性，一个方面讲scale up，一个方面讲scale out。要充分相信现代JVM（64位）虚拟机对我们程序的优化处理。

现在使用的这些框架，开发人员写个内存泄露的程序，要比写个正常的程序要难得多。一般我们遇到OOM无外乎以下几种（包括但不限于）

1、查询无分页

2、导入大量数据无控制

3、导出大量数据无控制

4、线程等待IO处理，大量线程挂起状态

等等

避免上述情况的出现，正常的业务处理数据量来了以后，我们要做的就是scale，选择up或是out，就是一个选择的问题了。