2017年3月

Jvm一共分配60G内存，old区涨到27G+之后，发生一轮old区的大规模回收，结束后old区降为8G。
原本以为会是一次full gc，或一次mixed gc，实际上是以一次带(initial-mark)的较长时间（600+毫秒）young gc开始，然后是一系列处理，其中remark是STW的，且耗时较长（300+毫秒），随后跟着一次young GC和三次mixed GC，这四次GC每一次old区都会下降，第三次mixed GC后，old区降到最低的8G，应该是本轮GC的结束。

找到一遍文章，对G1做了比较详细的解释：Understanding G1 GC Logs
这一轮过程被称为并发标记（concurrent-marking），从[initial-mark]起到[GC concurrent-cleanup-end]止，不包括后面的一次young GC和三次mixed GC。猜测是后续gc时会根据限定的暂停时间自动回收相应的内存。
其中较慢（300+毫秒）的remark(SATB buffers processing) 和较快（20+毫秒）的cleanup是stop-the-world（STW）的。
clean up: Cleanup phase which is again a stop-the-world phase. It goes through the marking information of all the regions, computes the live data information of each region, resets the marking data structures and sorts the regions according to their gc-efficiency.
大意是：Cleanup操作也是STW的，它通过各区标记的信息计算存活对象，重置这些数据结构，然后根据GC的效率对各区排序。

jvm启动参数：
[code]
java -server -Xmx60g -Xms60g -XX:MaxGCPauseMillis=300 -XX:PermSize=128m -XX:MaxPermSize=256m -Xss256k -XX:+DisableExplicitGC -XX:+UseG1GC -XX:LargePageSizeInBytes=128m -verbose:gc -Xloggc:/data/logs/gc_xxx.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -jar xxx.jar
[/code]

先用jstat看整体GC的统计
[code]
[root@xxxx logs]# jstat -gcutil 2450 1000
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 100.00 58.62 41.51 71.09 3869 474.469 0 0.000 474.469
0.00 100.00 59.96 41.51 71.09 3869 474.469 0 0.000 474.469
[/code]
没有Full GC，OLD区已经从昨天看到的80+%降到41%

- 阅读剩余部分 -

一、关于struct的Field反射
1、取结构或值时，传对象和指针都可以。
2、给某struct通过反射赋值时，必须是reflect.ValueOf传指针进去。如果用的是函数的入参且为值参时，对象为副本，取地址也不能设置其值。

二、关于struct的method反射
传入值时，得不到任何method，因为值只包括Field；传指针才可能得到method

三、反射可以得到未导出（首字母小写）的field和method，但不能操作它们，会抛using unexported xxx异常

四、Type有可能被包n层壳，有Ptr和interface两类，可以用Type的.Elem()脱一层壳。

五、Value可以通过interface()方法得到对应的对象实例。Value同样有Ptr和interface的脱壳问题。

六、go没有Java强大的注解，只有Struct tag，神奇的是这个tag是可以在运行时修改的。比如：对象转json时，需要首字母小写，就可以统一来处理，不用手工挨个写。
后经证实，可以修改，但未真正生效，重新反射获取时，还是老的，具体参照：go中StructTag的修改问题

七、struct的method通过反射调用时，struct对象本身会被当成第一个参数，也就是入参看起来比定义的时候多了一个。其实Java也是这么做的。method调用的返回值是[]reflect.value，因为go支持多个返回值。