linux分析与调优JVM/GC
<h3>一、JVM的GC参数：</h3>
<p><img src="http://60.191.64.5:16100/server/index.php?s=/api/attachment/visitFile/sign/cb21c346b7256fa45163d7446640baa7" alt="" /></p>
<pre><code>-Xms : 初始堆大小6G
-XX : CMSInitiatingOccupancyFraction=65 ：年老代空间使用率到65%就执行CMS GC。从70调整为65，让old区尽早的进行回收，可以保证年老代能及时回收垃圾，保证空间充足可以接纳新声代对象</code></pre>
<h3>二、堆内存heap</h3>
<h4>1.年轻代（Young Generation）、老年代（Old Generation）和持久代（Permanent Generation）</h4>
<p>(1）年轻代:</p>
<pre><code> 所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。 一个eden区，两个Survivor区(一般而言)。大部分对象在Eden区中生成。</code></pre>
<p>（2）年老代:</p>
<pre><code> 在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。</code></pre>
<p>（3）持久代:</p>
<pre><code> 用于存放静态文件，如今Java类、方法等</code></pre>
<p><img src="http://60.191.64.5:16100/server/index.php?s=/api/attachment/visitFile/sign/923334a14afb374240cf1db3dea8d15c" alt="" /></p>
<p>2.内存回收触发
（1）Young GC：</p>
<pre><code> 条件：eden满了。只整理回收young gen</code></pre>
<p>（2）CMS GC：全称 Concurrent Low Pause Collector</p>
<pre><code> 条件：old Gen的使用率大于一定的比率，默认为92%。在并发模式工作的时候只整理回收old gen。</code></pre>
<p>（3）Full GC：（Full GC很影响系统性能）</p>
<pre><code> 条件：
年老代满了；
持久代满了；
【CMS GC出现promotion failed（年轻代晋升到年老代空间不足）和concurrent mode failure（并发失败）。Full GC将对整个堆进行整理。 】</code></pre>
<p><img src="http://60.191.64.5:16100/server/index.php?s=/api/attachment/visitFile/sign/1727160f6da9513b1d42ef054fa0506f" alt="" /></p>
<h3>三、查看回收情况</h3>
<p>堆溢出是因为对象一直在产生，一直存活，堆在了old区，对象产生的速度比GC都快，越来越多就会溢出了。
Full GC如果太大，一次GC就会花太多时间</p>
<pre><code>幼儿期(Young GC)---&gt;年轻态（S0,S1幸存区，存活区）---&gt;年老区
幼儿期：最容易消亡的，这个时期会频繁发生Young GC。回收的最快
年轻态：大量对象都要经历的过程，如果这个对象一直被使用的话，会把上一个时期的转到这个阶段里面来S0,S1
年老区：如果年轻态阶段的对象还是一直有人使用的话，会转到这个阶段。回收的最慢</code></pre>
<p><code>jstat -gc pid 1000 5（1000：毫秒 5 次数）</code></p>
<pre><code>S0C：S0区容量（S1区相同，略）
S0U：S0区已使用
EC：E区容量
EU：E区已使用
OC：老年代容量
OU：老年代已使用
PC：Perm容量
PU：Perm区已使用
YGC：Young GC（Minor GC）次数
YGCT：Young GC总耗时
FGC：Full GC次数
FGCT：Full GC总耗时
GCT：GC总耗时</code></pre>
<p>注意事项：</p>
<pre><code>Jvm堆大小=年轻代+年老代
年轻代 = 年轻代-1+S0+S1 注意 年轻代-1、S0、S1三者是实际是动态调整的，总和是年轻代
Java的阻塞式的线程模型基本上可以抛弃了，目前成熟的NIO框架也比较多了。阻塞式IO带来的问题是
线程数量的线性增长，而NIO则可以转换成为常数线程。因此，对于服务端的应用而言，NIO还是不错
的选择</code></pre>