成功记一次营销场景大对象不回收，吞吐量低GC调优

我们重头说一次GC

1：C和C++既要写构造函数，又要写析构函数释放内存，能不能写一段程序实现-复用析构函这段代码
2：1960年麻省理工（MIT）Lisp 首先提出了垃圾回收的概念，而这时 Java 还没有出世

1：哪些内存是需要回收的尼？
    引用计数器算法：有引用+1，没有引用-1，当等于0的时候就回收；引用计数的垃圾收集不属于严格意义上的"Stop-The-World"的垃圾收集机制
    但是这两个对象都是这个应用程序不需要引用的，比如两个对象互相应用，这样也就是永远无法应用了
    
   真正的垃圾收集器：
 1可达性分析算法：当一个对象到 GC Roots 没有任何引用链相连时，证明这个对象不可以使用，然后回收这个对象
 
                怎么高校垃圾收集，接下来说说常见的垃圾收集算法
         1：标记算法，2复制算法，3整理标记算法
                               （除算法上做了升级，解决了内存碎片的问题，也规避了复制算法只能利用一半内存区域的弊端需要整理所有存活对象的引用地址，在效率上比复制算法要差很多）
                                分代收集算法严格来说并不是一种思想或理论，而是融合上述3种基础的算法思想       
                
  大对象
  大对象指需要大量连续内存空间的对象，都会直接进到老年代。为了避免在 Eden 区及2个 Survivor 区之间发生大量的内存复制。
  当你的系统有非常多“朝生夕死”的大对象时，得注意了。
 
长期存活对象
对象在 Survivor 区中每经历一次 Minor GC，年龄就增加1岁。当年龄增加到15岁时，这时候就会被转移到老年代。当然，这里的15，JVM 也支持进行特殊设置。

动态对象年龄
如果 Survivor 空间中相同年龄所有对象大小的总合大于 Survivor 空间的一半，
年龄大于等于该年龄的对象就可以直接进去老年区，无需等你“成年”。

这其实有点类似于负载均衡，轮询是负载均衡的一种，保证每台机器都分得同样的请求。看似很均衡，但每台机的硬件不通，
健康状况不同，我们还可以基于每台机接受的请求数，或每台机的响应时间等，来调整我们的负载均衡算法。:

2：JVM那点事-垃圾收集器

jdk8环境下，默认使用 Parallel Scavenge（新生代）+ Serial Old（老年代）（注重吞吐量以及CPU资源敏感的场合，适合大部分系统）

Parallel Scavenge收集器（并行收集器）
标签：新生代收集器 复制算法 多线程收集器 吞吐量优先

Parallel Old收集器（并行收集器）
Serial Old（老年代）收集器 标记-整理算法 多线程收集器 吞吐量优先

CMS收集器（并发收集器）[停顿时间少，适合互联网使用]
标签： 老年代收集器 标记-清除算法 低停顿时间 并发收集器 CPU资源敏感 浮动垃圾 内存碎片
CMS（Concurrent Mark Sweep）收集器是一种获取最短回收停顿时间为目标的收集器。目前很大一部分的java应用集中在互联网或者B/S系统的服务端上。重视响应速度，希望系统停顿时间最短。
初始标记：标记GC Roots 直接关联的对象。
并发标记：获取初始标记的节点做为根节点，并发标记对象。
重新标记：修正并发标记过程中变动的对象。如何修改？就是将并发标记阶段变化的对象记录在线程Remembered Set Logs线程，在重新标记阶段，将数据合并到Remember Set中。（PS：详见G1收集器描述）
并发清除：并发清除对象

6. G1收集器（并发收集器）（空间整合，内存化整为零，适合crm营销系统）
标签： 分代收集 空间整合 并发收集 可预测停顿 内存化整为零

初始标记（Initial Marking）：暂停线程，标记GC Roots能直接关联到的对象。
并发阶段（Concurrent Marking）：对堆中的对象进行可达性分析，耗时较长，可并发执行；
最终阶段（Final Marking）：修正并发阶段期间用户程序运行导致标记产生变化的记录；* （敲黑板，继续划重点）*虚拟机将这段时间对象变化在线程Remembered Set Logs中，最终阶段需要把Remembered Set Logs数据合并到Remembered Set中，需要停顿线程，但可并行执行。

筛选阶段（Live Data Counting and Evacuation）：根据用户期望的GC停顿时间制定回收计划。也可做到与用户程序并行执行。

3-修改启动命令，1改大内存，2使用G1GC，3对象每次拉取行数减少 大对象回收了，吞吐量也高了

java -jar -Xms8192m -Xmx8192m -XX:+UseG1GC -Djava.io.tmpdir=/work1/tmp -XX:+PrintGC -Xloggc:/work1/prod-members/gclogs/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/work1/prod-members/dump.hprof members.jar --spring.cloud.nacos.config.namespace=1dcbc03f-4430-45b6-8682-8826050ce345 --spring.cloud.nacos.config.server-addr=172.16.147.202:8848