JVM 调优主要是调整GC以及一些执行参数：

目标：

堆不要太大，不然单次GC的时间过长导致服务器无法响应的问题

压力测试的时候TPS平稳

尽量避免full GC

检查是否用了并行的垃圾回收器

参数：

-server执行，开启优化

采用并行gc collector, -XX:+UseParallelGC +XX:+UseParallelOldGC +XX:+UseConcMarkSweepGC

-Xmx不要太大，不然单次gc的过程可能太长，大内存机器可以采用多个实例的方式

-Xms不要太小，不然jvm需要多次调整堆的大小，增加gc次数，影响了启动性能。

同理-XX:MaxPermSize

-XX:NewRatio新生代与老年代的比例要合适，这个需要看应用类型，一般新生代的对象很快就会被GC掉了。

线程池的大小要合适，线程上下文切换也是很耗资源的。

不要去调整一些你不完全了解的参数。

还有-Xverify:none可以加快启动速度，但字节码问题查错很麻烦。

字节码调优应该避免吧，容易触发一些jvm本身的bug，这些参数缺少实际场景的测试。

CMS垃圾收集器的相关参数，请读取相关资料。貌似CMS不会去移动对象的去使得空间更加紧凑。

G1垃圾收集器的工作原理，G1可以Compact Heap Region以减少内存碎片问题。

相关链接：一个Oracle jvm部门里面的员工的blog: https://blogs.oracle.com/jonthecollector/ 里面的文章很有价值。

一些命令:

1
2
3
4
5
6
1// 监控gc的情况，每隔2秒输出一次gc的信息

2jstat -gcutil pid 2000

3

4// 每列的语言如下

5S0(Survivor0) S1(Survivor1) E(Eden) O(Old) P(Perment) YGC (Young GC Count) YGCT(Young GC Time) FGC(Full GC Count) FGCT(Full GC Time)

6

 Memory Management In The Java HotSpot Virtual Machine

1、为什么要使用自动内存管理

为了消除手动内存管理带来的复杂性以及内存泄漏，dangling引用，内存碎片等一系列问题

2、动态内存分配是一个比较复杂的工作，因为它要使用内存的分配及释放足够快，同时还要考虑内存碎片问题。

3、垃圾回收器必须尽量少使得程序暂停，同时也需要在 回收耗时、空间大小，回收次数这几个方面取得一个平衡，另外还需要控制内存碎片。

4、垃圾回收器必须是可扩展，它不应该成为程序性能的瓶颈，它应该可以在多线程/多CPU的环境并行得执行。

5、垃圾回收器最好能够并发地进行内存回收工作，并发情况下，堆被划分成几个区域，这些区域会被并发地进行回收，由此减少了回收工作所引起的程序的暂停。

6、Compacting vs Non-Compacting vs Copying

7、垃圾回收器性能评判的几个指标：GC时间占程序运行时间的比重，非GC时间占比，GC引起的暂停时间，回收的频率，检测到垃圾对象的速度，回收器工作消耗的内存大小。

8、内存分代回收，比较流行分为young generation（新生代）及old generation（老年代），大多数分配的对象不会存活得太久，通常只有一小部分对象可以进化到老年代。因此新生代的区域回收得比较频繁，而老年代空间通过占用比较多的空间，因此各个区域会使用不同的算法进行垃圾回收。比如-XX:NewRatio=4表示 young generation : old generation = 1 : 4。在HotSpot Virutial Machine中，内存被分为三个区域，young generation, old generation和permenent generation，大部分对象都是在新生代进行分配的，有些对象会直接在老年代进行分配。新生代的空间由Eden生两个survivor区域来组成，一个survivor用来存放至少存活超过一次young generation GC的对象，而另一个survivor空间是空的，直接下一次回收的时候会被使用。一个suvivor与Eden的大小比值可以用-XX:SurvivorRatio=n来表示（1/n=survivor : Eden）

当old generation因塞满而无法存放young generation升级上来的对象时，将触发full GC，这时大部分的收集器会用老年代的算法去GC整个Heap（除了CMS Collector外， CMS Collector的老年代算法无法回收新生代区域）。

快速分配，在大片连接的内存块中进行分配内存的效率是很高的，可以利用bump-the-pointer技术来进行分配，分配器会记住下一次分配的起点。对于多线程的程序来说，内存分配操作需要是线程安全的，如果使用全局锁的话这会降低性能并造成性能瓶颈，相应的HotSpot采用一种叫做Thread-Local Allocation Buffers的技术（线程自己的内存分配缓冲区），使得减少获取全局锁的操作，通常TLAB占用大概1%的Edgen的大小。结合TLAB和bump-the-pointer技术，通常分配一个对象空间只需要10条本地指令。

Serial Collector

young generation使用Serial Collector进行回收的过程

当使用Serial Collector时候，young generation和old generation的回收工作都是使用单个CPU线性执行的，回收过程中将stop-the-world。下图展示了Serial Collector对young generation进行回收时过程，Eden区域存活的对象被复制到那个空的Survivor块（图中用to标记），如果对象太大超出了Survivor的大小，那么它将直接被copy到old generation区域，而非空的survivor（图中用from标记）中仍然年轻的对象也被复制到空的survivor中（图中用to标记），而相对比较“老”的对象则被复制到old generation区域中。

注意：如果"To" survivor被塞满了话，Eden和"From"Survivor区域还没有被copy的对象将直接被复制到old generation中（无论它们存活多少了多少代）。

在完成了对young generation的回收之后，young generation中Eden区域和"From" survivor都被被清空，只有"To" survivor中有存活的对象。这时，"From"和"To" Survivor将对换，如下图所示：

注意，存在old generation引用young generation对象的情况，为了避免进行young gc的时候扫描old generation，老年代对new generation的引用被记录在一个叫做card table的cache中。

old generation使用Serial Collector进行回收的过程：

当使用Serial Collector对old generation和permenent generation进行回收的时候，它将使用一种mark-sweep-compact的回收算法：

Mark阶段：Collector检测那些对象仍然存活。

Sweep阶段：Collector扫描整个old generation或者permenent generation，

Compact阶段：Collector将存活的对象“滑动”到old generation的首部，所有连续的空间放在old generation的尾部，这样方便利用bump-the-pointer来实现快速地分配对象。如下图所示：

什么时候应该使用Serial Collector。

大部分以Client-Style（java -client）运行的程序都使用这种收集器，这类程序对回收引种的程序暂停时候不敏感。在现在的硬件条件下，Serial Collector能够管理64MB大小的堆空间（现在应该可以256MB了吧）。

在JavaSE5中，运行非server-class的机器上默认使用Serial Collector，但用户可以使用-XX:+UseSerialGC命令参数来指定使用Serial Collector。

Parallel Collector（也被称为Throughput Collector）

如今，很多程序运行在拥有大内存多CPU的机器上面，Parallel Collector就是为了在垃圾回收过程中充分利用CPU资源而开发的。

使用Parallel Collector对young generation进行垃圾回收的过程：

Parallel Collector使用一种类似于Serial Collector对young generation回收的算法的并行版本，回收时它仍然会stop-the-world，但在回收的过程中它并行地使用多个cpu并行地执行，由些来减少垃圾回收所占用的时候并提升程序运行时间的占比。

使用Parallel Collector对old generation进行回收

Parallel Collector使用了与Serial Collector同样的mark-sweep-compact的回收算法。

什么时候使用Parallel Collector

运行在多cpu以及对停止时间不敏感的程序可以从使用parallel collector中受益，不频繁，耗时较长的针对old generation区域回收的仍然会发生， 批量处理，计费，工资以及科学计算这类程序比较适合使用Parallel Collector。

JavaSE5中，运行server-class的机器上默认使用Parallel Collector，用户可以使用-XX:UseParallelGC命令参数来显示指定使用Parallel Collector

Parallel Compacting Collector

Parallel Compacting Collector在JavaSE5.0 update 6被引入，与Parallel Collector不同的是，它使用了一种新的算法来对old generation进行回收，最终Parallel Compacting Collector将取代Parallel Collector

回收young generation时，Parallel Compacting Collector使用了与Parallel Collector同样的算法。

回收old generation和permenent generation时，Parallel Compacting Collector仍然会stop-the-world，但在整理存活对象的时候大部分是并行的。Parallel Compacting Collector使用三个阶段进行，

１、young/old/permenent generation区域被划分成几个固定大小的区域

２、marking阶段，程序中仍然可以引用到的存活的对象被划分给几个garbage collection threads中，然后mark工作是并发执行地，当一个对象被标记为存活的时候，它所在的regioin的大小将会被更新。

３、Summary阶段，通过前几次的收集，generation空间的首部会存活的对象会比较密集，通过compacting能回收的空间比较少，因此不值得在上面进行compacting，所以summary阶段所做的第一件事就是检验regions的密度，从最左边开始，直到碰到一个密度比较小，值得花时间去compacting的region，然后从这个region开始，compacting右边的region。summary阶段计算并存放被compacting region的新的首地址（这个阶段并没有真正地去Compacting）。注意：summary段是单线程执行的，尽管它可以实现为并发执行。但事实表明并发执行的

４、compacting阶段，在这个阶段中，利用上一阶计算出来的Compacting信息，各个线程可以独立地往region移动对象。Compacting完成之后，堆空间的后部将释放出一片连续的空间。

什么时候使用Parallel Compacting Collector

在Parallel Collector的基础上，Parallel Compacting Collector进一步减少了由于回收old generation所消耗的时候，进一步满足对垃圾回收引起的暂停时间　比较敏感的程序。但需要注意的是，Parallel Compacting Collector 可以不适合那些运行在大型机/刀片机的程序，这种机器上是不允许单独一个程序占用几个cpu过长时间，在这种环境下可以考虑利用参数-XX:ParallelGCThread=n，或者选择另外的垃圾回收器。

需要使用-XX:+UseParallelOldGC来显式指定使用Parallel Compacting Collector，这个参数的名字有点奇怪，这里的"Old"是指old generation。

Concurrent Mark-Sweep (CMS) Collector

对于很多应用来说，应用运行时间占比（throughput）没有响应时间这么重要，young generation区域的回收通常不会造成太长时间的暂停。但是old generation的回收，尽管不是很频繁，但通常会强制应用暂停比较长的时间。为了解决这个问题，HotSpot JVM 引入了一个叫做concurrent mark-sweep (CMS)的收集器，也叫做low-latency collector（低延迟回收器）

CMS回收young generation的过程：

CMS与Parallel Collector使用同样的方式回收young generation

CMS回收old generation的过程：

CMS在回收old generation大多数时候都是在程序运行时并发地执行，在开始一次完整的回收之前，CMS需要暂停一下程序(stop-the-world)，这个过程叫做初始标记（Initial Mark），这个过程中查找程序代码中可以直接引用到的对象（通常是线程栈上的对象引用），然后在并发标记阶段，CMS去标记所有可达的对象，因为这个工作是并发进行的，应用同时也在更新一些字段的引用，所以在并发标记之后需要来一个stop-the-world，将新产生的对象标记完整，这个过程被称为remark，remark比initial mark更加耗时，所以一般使用多个线程并发地执行来提交效率。

在remark结束之后，所有的可达的对象都被标记了，然后接下来的并发扫描阶段将回收垃圾，下图阐述了CMS Collector与Serial  mark-sweep-compact Collector之间的差别：

 因为有一些工作，比如在remark阶段重新遍历对象，增加了collector的工作量，所以CMS回收时占用的CPU和内存资源也更多，但它减少了应用的停止时间。

需要注意的是，CMS collector是唯一一个不会去compact（整理）内存的收集器，如下图所示，这节省了一些时间，但因为这些空间并不连接，bump-the-pointer也不奏效了，因此它需要使用一个free列表去记录可使用的空间，然后在分配时去查找这个list。因此分配空间的操作效率相对要低一些，同时，这也会造成回收young generation的一些负担，因此回收young generation时需要从young generation里面复制一些存活的对象到old generation中，内存碎片的风险也增加了。

另外，与其它收集器不同的是，当old generation满了之后，它并不会发起一个old generation的回收，相反，它会尝试在还没有满的时候发起一次回收（因为在concurrent mark阶段程序是并发运行地），以便能够用完之前能够完成回收，否则它将转为使用与parallel collector 和serial collector一样stop-the-world方法去回收这部分空间。为了避免这一点，CMS Collector定时记录了一些垃圾回收的数据，比如回收的速率，然后在恰当的时候触发回收操作，避免在用完的时候再进行回收。另外，当old generation占用超过一定程度之后，CMS Collector也会去发起一次回收操作，可以用-XX:CMSInitiatingOccupanyFraction=n，n是old generation大小的占比，默认是68。

总之，CMS能够减少大部分程序由于回收工作而被暂停的时间 ，但结果的代价是：回收young generation变慢了，程序运行时间占比下降，以及更大的堆空间消耗。

增量式的回收

CMS Collector可以运行在增量回收的模式下，这种模式下，young generation回收过程的时候被分为几个小块的时间段。以减少stop-the-world时间。

CMS Collector适合那些对暂时时间比较敏感，允许GC操作并发地使用CPU，而且有大量存活对象的应用，比如web server。

必须使用-XX:+UseConcMarkSweepGC来显示指定使用CMS Collector，如果需要运行在增量模式下，必须使用-XX:+CMSIncrementalMode参数。

 默认堆大小

在-server模式下，jvm的默认初始heap大小是1/64的物理内存（最多1GB），默认最大堆大小是1/4物理内存大小（最大1GB）

-client模式下，默认4MB初始heap大小及64MB的最大堆大小。当然这些都可以通过命令参数进行覆盖。

其它参数

另外还可以使用-XX:MaxGCPauseMillis=n来指定GC造成的最大停顿时间，这个时间不一定能完成，不能完成的话，Collector会在堆未占满的情况触发回收操作。

另外也可以使用-XX:GCTimeRatio=n来设置GC时间占比（GC:程序运行时间），比如GCTimeRatio=4的情况下，GC时间将最大占用20%的时间。和-XX:MaxGCPauseMillis一样，如果不能满足要求，Collector将在geneartion占满之前触发回收操作。