网络上有很多文档，我也抄记很多内容到有道去笔记，可是那些东西都是别人的，
只通过消化测试总结才算是自己的内容，所以我也抄袭一下吧.
先上传一张图, 主要是对JVM GC收集器的对比说明，根据链接内容，做出自己的理解.
http://hllvm.group.iteye.com/group/topic/37095此链接的内容对我很我帮助.
# cat gccheck.sh
#!/bin/bash
#没有注释 20150916
filename="/data/resin/log/jvm-app-a.log"
thistime=0.0
lasttime=0.0
tail -100 $filename | awk '/\[GC/' | while read line
do
echo $line | egrep -q 'CMS-initial-mark|YG occupancy'
if [ $? -eq 0 ];then
echo $line | awk '/CMS-initial-mark/{printf "%d %s %s, ",$1/60,$1,$(NF-1)};/YG occupancy/{print $1,$(NF-1)}'
continue
fi
midline=$(echo $line | sed 's#\[##g;s#\]##g;s#:##g;s#(# #g;s#)##g;s#,##g;s#K##g;s#-># #g;')
rate=$(echo $midline | awk '{printf "%.0f\n",($10-$7)/($12-$7)*100}')
ygk=$(echo $midline | awk '{printf "%d\n",$5-$6}')
heapk=$(echo $midline | awk '{printf "%d\n",$10-$11}')
thistime=$(echo $midline | awk '{print $3}')
interval=$(echo "$thistime-$lasttime"|bc)
usedtime=$(echo $midline | awk '{printf "%d\n",$8*1000}')
let total=ygk-heapk
if [ $total -gt 0 ];then
echo -e "YG减少的数据量 $ygk HEAP堆减少量 $heapk \033[31m间隔时间为 $interval 持续时间为 $usedtime 转移内容到OG为+$total KB \033[0m当前OG占有率 $rate%"
else
echo -e "YG减少的数据量 $ygk HEAP堆减少量 $heapk \033[31m间隔时间为 $interval 持续时间为 $usedtime 转移内容到OG为-$total KB\033[0m当前OG占有率 $rate%"
fi
lasttime=$thistime
sleep 0.05
done
也是抄别人的，自己改了一下，主要是对GC回收过去进行查看.
13449.991: [GC 13449.991: [ParNew: 344566K->17482K(368640K), 0.0272580 secs] 734079K->407266K(1495040K), 0.0274010 secs] [Times: user=0.10 sys=0.01, real=0.03 secs]
13488.107: [GC 13488.107: [ParNew: 345162K->17620K(368640K), 0.0378120 secs] 734946K->410438K(1495040K), 0.0379860 secs] [Times: user=0.13 sys=0.00, real=0.03 secs]
13516.941: [GC 13516.941: [ParNew: 345300K->12992K(368640K), 0.0198980 secs] 738118K->406392K(1495040K), 0.0200320 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
简单脚本分析,通过打印日志了解JVM回收健康情况,抄抄改改.
可以了解到每次YGC的垃圾回收和对象实例转移情况, 我认为间隔35秒,YGC持续25秒左右的
哎呀，这个脚本还有修改一下.
执行 bash gccheck.sh会产生以下可视化内容.
YG减少的数据量 327084 HEAP堆减少量 326813 间隔时间为 36.019 持续时间为 27 转移内容到OG为+271 KB 当前OG占有率 32%
YG减少的数据量 327542 HEAP堆减少量 324508 间隔时间为 38.116 持续时间为 37 转移内容到OG为+3034 KB 当前OG占有率 33%
YG减少的数据量 332308 HEAP堆减少量 331726 间隔时间为 28.834 持续时间为 19 转移内容到OG为+582 KB 当前OG占有率 33%
############################################################
经过对网上内容的抄袭，终于得出这样的配置内容.
命令查看jvm信息,jmap jstat
#以下是jstat打印GC回收情况,那个FGCT为2是刚启动应用时出现些问题，稳定一天左右就会回归到70ms左右.
#另外那个YGC大约维持25ms左右，我觉得已经很赞，我的水平就是这样.
# /usr/java/jdk/bin/jstat -gcutil -h30 8828 1s
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 35.76 85.10 36.73 50.36 421 10.026 2 1.654 11.680
0.00 35.76 90.37 36.73 50.36 421 10.026 2 1.654 11.680
0.00 35.76 92.28 36.73 50.36 421 10.026 2 1.654 11.680
35.39 0.00 0.34 36.78 50.36 422 10.050 2 1.654 11.704
35.39 0.00 2.51 36.78 50.36 422 10.050 2 1.654 11.704
35.39 0.00 4.96 36.78 50.36 422 10.050 2 1.654 11.704
----------------------------------------------------------------------------------------------
# /usr/java/jdk/bin/jmap -heap 8828
Attaching to process ID 8828, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.7-b02
using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 1572864000 (1500.0MB)
NewSize = 419430400 (400.0MB)
MaxNewSize = 419430400 (400.0MB)
OldSize = 5439488 (5.1875MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 134217728 (128.0MB)
MaxPermSize = 268435456 (256.0MB)
#一将功成万骨枯,java程序内存资源很宝贵......
Heap Usage:
New Generation (Eden + 1 Survivor Space): #一个eden区和两个S区(两者只能存在一个),实际可用NG为360MB
capacity = 377487360 (360.0MB)
used = 140504056 (133.99510955810547MB)
free = 236983304 (226.00489044189453MB)
37.22086376614041% used
Eden Space: #E区使用情况
capacity = 335544320 (320.0MB)
used = 125658376 (119.83716583251953MB)
free = 209885944 (200.16283416748047MB)
37.44911432266235% used
From Space: #此处S区from空间分配为1:1:8,实际为10%(400MB),最后是40MB,可是有时不会得到这个值.
capacity = 41943040 (40.0MB)
used = 14845680 (14.157943725585938MB)
free = 27097360 (25.842056274414062MB)
35.394859313964844% used
To Space: #同上
capacity = 41943040 (40.0MB)
used = 0 (0.0MB)
free = 41943040 (40.0MB)
0.0% used
concurrent mark-sweep generation: #以前调整的时候，总会遇到内存碎片,这次终于正常了，呵呵.
capacity = 1153433600 (1100.0MB)
used = 424188544 (404.5377197265625MB)
free = 729245056 (695.4622802734375MB)
36.77615633877841% used
Perm Generation: #根据上面的配置,PG一般会维持在50%左右，我这次分配128MB
capacity = 134217728 (128.0MB)
used = 67596336 (64.46488952636719MB)
free = 66621392 (63.53511047363281MB)
50.363194942474365% used
----------------------------------------------------------------------------------------------
优化结果和跟进
----------------------------------------------------------------------------------------------
说明64位VM机器和JDK,内存4G
1.resin jvm1.5G(400+1100),mc缓存分配1G,为提高信息读写速度使用NIO技术,
使用bytebuffer. allocate分配内在,此处DirectMemorySize也最大设置为1G.
2. 通过free -m了解到SWAP还是有731M在使用,实际想不到是哪个进程在使用.
ps aux结果为以下内容
java区RES1.2G为heap堆部分,swap部分应该为nio bytebuffer使用的1G加速空间.
mc区分配1G空间,数据跳出率很高,此处swap 468M应该是MC的影响.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP DATA COMMAND
8828 xxx 15 0 2282m 1.2g 12m S 6.7 31.4 37:31.03 1.0g 2.1g java
4128 yyy 15 0 1307m 839m 560 S 2.3 21.2 5445:57 468m 1.3g memcached
3.MC的状态信息 主要还是觉得有必要优化一下MC，学学学
curr_items 399754 现在的条目只有40万条
total_items 418833290 总共活跃条目4.1亿次
evictions 148384635 数据跳出率1.4亿次
RunDays 140 days
Items 399754
MaxMem 1024 MByte
Usage 57.20 %
HitRate 86.23 %
以下为MC的资源池分配情况,group 29 30占用过多资源,导致group 8 9次没有资源使用,结果消耗系统swap资源.
# xmemcached.pl localhost:11211
# Item_Size Max_age 1MB_pages Count Full?
8 480 B 15067 s 27 58853 yes
9 600 B 29830 s 33 57651 yes
10 752 B 8255 s 28 39032 yes
29 51.7 kB 29275 s 742 8263 yes
30 64.7 kB 3095 s 138 857 yes
标记：优化其应用，通过控制jvm大小和算法来优化，当然找到内存泄漏代码并解决问题才是最重要.
可是目前只会这样，通过此文希望能再接再励吧.
感觉以下链接内容:
http://www.iteye.com/topic/212967
http://www.iteye.com/topic/212967
http://www.iteye.com/topic/473874
http://blog.csdn.net/fenglibing/article/details/6321453
http://hllvm.group.iteye.com/group/topic/27945