收集器简介
https://blogs.oracle.com/jonthecollector/our-collectors
| 收集器 | 串行、并行or并发 | 新生代/老年代 | 算法 | 目标 | 适用场景 | 权威解释 |
|---|---|---|---|---|---|---|
| Serial | 串行 | 新生代 | 复制算法 | 响应速度优先 | 单CPU环境下的Client模式 | "Serial" is a stop-the-world, copying collector which uses a single GC thread. |
| Serial Old | 串行 | 老年代 | 标记-整理 | 响应速度优先 | 单CPU环境下的Client模式、CMS的后备预案 | "Serial Old" is a stop-the-world,mark-sweep-compact collector that uses a single GC thread. |
| ParNew | 并行 | 新生代 | 复制算法 | 响应速度优先 | 多CPU环境时在Server模式下与CMS配合 | "ParNew" is a stop-the-world, copying collector which uses multiple GC threads. It differs from "Parallel Scavenge" in that it has enhancements that make it usable with CMS. For example, "ParNew" does the synchronization needed so that it can run during the concurrent phases of CMS. |
| Parallel Scavenge | 并行 | 新生代 | 复制算法 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 | "Parallel Scavenge" is a stop-the-world, copying collector which uses multiple GC threads. |
| Parallel Old | 并行 | 老年代 | 标记-整理 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 | "Parallel Old" is a compacting collector that uses multiple GC threads.Using the -XX flags for our collectors for jdk6 |
| CMS | 并发 | 老年代 | 标记-清除 | 响应速度优先 | 集中在互联网站或B/S系统服务端上的Java应用 | "CMS" is a mostly concurrent, low-pause collector |
| G1 | 并发 | both | 标记-整理+复制算法 | 响应速度优先 | 面向服务端应用，将来替换CMS |
JVM 对应选项的回收器组合
- UseSerialGC is "Serial" + "Serial Old"
- UseParNewGC is "ParNew" + "Serial Old"
- UseConcMarkSweepGC is
"ParNew" + "CMS" + "Serial Old". "CMS"is used most of the time to collect the tenured generation. "Serial Old" is used when a concurrent mode failure occurs.
whyhttps://stackoverflow.com/questions/39569649/why-is-cms-full-gc-single-threaded?from=timeline&isappinstalled=0 简单翻译一下:因为开发人员的精力都在G1上，而且 CMS发现FULL GC的情况很少，另外每个回收器的内存实现很复杂，不能简单地进行兼容，需要开发。所以没有支持para old,但已经提了patch,只不过没有快实现 - UseParallelGC is "Parallel Scavenge" + "Serial Old"
- UseParallelOldGC is "Parallel Scavenge" + "Parallel Old"
JDK版本默认垃圾收集器
jdk1.7 默认垃圾收集器Parallel Scavenge（新生代）+Serial Old（老年代）
jdk1.8 默认垃圾收集器Parallel Scavenge（新生代）+Serial Old（老年代）
jdk1.9 默认垃圾收集器G1
jdk10 默认垃圾收集器G1
-XX:+PrintCommandLineFlags jvm参数可查看默认设置收集器类型
java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=132435328 -XX:MaxHeapSize=2118965248 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
java version "1.8.0_221"
Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode)
常用的收集器组合
https://blogs.oracle.com/jonthecollector/our-collectors
再谈引用
小哥的公司和正常的公司发展没有多大不一样,客户关系越来越复杂，有的客户很不规矩，经常把人介绍进来，然后忘了带走，扫地阿姨不敢给赶走，因为不确定这哥们会不会还有用。时间一长，这种客户越来越多，办公区域又不够了。这种情况有两种，一种是VIP区域中没有关系的用户，这种用户当VIP区域的扫地阿姨发现空间不足时，会被清掉！但如果这种用户太多，也会增阿姨的负责，阿姨清扫的时间长，影响客户体验。
第二种是到VIP区域后依赖有关系的用户，老板的亲戚。解决这种问题的办法从根源上杜绝走后门。比如ThreadLocal 的remove（）方法。
深入thread local 本质
https://www.jianshu.com/p/fca69ba27de6