知识图谱(RocketMQ.MySQL,JVM,Redis)

第一种可能，Minor GC过后，剩余的存活对象的大小，是小于Survivor区的大小的，那么此时存活对象进入Survivor
区域即可。

第二种可能，Minor GC过后，剩余的存活对象的大小，是大于 Survivor区域的大小，但是是小于老年代可用内存大小
的，此时就直接进入老年代即可。

第三种可能，很不幸，Minor GC过后，剩余的存活对象的大小，大于了Survivor区域的大小，也大于了老年代可用内
存的大小。此时老年代都放不下这些存活对象了，就会发生“Handle Promotion Failure”的情况，这个时候就会触
发一次“Full GC”。是Full GC过后，老年代还是没有足够的空间存放Minor GC过后的剩余存活对象，那么此时就会导致所谓的“OOM”内存溢出了

一批对象的总大小大于这块Survior区域的内存大小的50%，那么大于等于这批年龄的对象直接进入老年代

JVM参数，就是“-XX:PretenureSizeThreshold”，可以把他的值设置为字节数，比如“1048576”字节，就是1MB。大于这个值对象直接进入老年代

这个时候就必须得把这些对象直接转移到老年代去

垃圾回收算法的速度至少比新生代的垃圾回收算法的速度慢10倍

造成内存碎片

这个阶段会让系统的工作线程全部停止，但是影响不大，因为速度很快，仅仅标记GC Roots直接引用的对象

这个阶段会让系统线程可以随意创建各种新对象，继续运行，对老年代所有对象进行GC Roots追踪，其实是最耗时的，需要追踪所有对象是否从根源上被GC Roots引用了

因为第二阶段里，你一边标记存活对象和垃圾对象，一边系统在不停运行创建新对象，让老对象变成垃圾，所以第二阶段结束之后，绝对会有很多存活对象和垃圾对象，是之前第二阶段没标记出来的，所以此时进入第三阶段，要继续让系统程序停下来，然后重新标记下在第二阶段里新创建的一些对象，还有一些已有对象可能失去引用变成垃圾的情况，这个重新标记的阶段，是速度很快的，他其实就是对在第二阶段中被系统程序运行变动过的少数对象进行标记，所以运行速度很快。

这个阶段就是让系统程序随意运行，然后他来清理掉之前标记为垃圾的对象即可，这个阶段其实是很耗时的，因为需要进行对象的清理，但是他也是跟系统程序并发运行的，所以其实也不影响系统程序的执行

问题：在并发标记和并发清理两个最耗时的阶段，垃圾回收线程和系统工作线程同时工作，会导致有限的CPU资源被垃圾回收线程占用了一部分，CMS的垃圾回收线程是比较耗费CPU资源的。CMS默认启动的垃圾回收线程的数量是（CPU核数 + 3）/ 4

浮动垃圾

内存碎片问题

新生代执行速度其实很快，因为直接从GC Roots出发就追踪哪些对象是活的就行了，新生代存活对象是很少的，这个速度是极快的，
不需要追踪多少对象，然后直接把存活对象放入Survivor中，就一次性直接回收Eden和之前使用的Survivor了

在并发标记阶段，他需要去追踪所有存活对象，老年代存活对象很多，这个过程就会很慢，其次并发清理阶段，他不是一次性回收一大片内存，而是找到零零散散在各个地方的垃圾对象，速度也很慢，最后完事儿了，还得执行一次内存碎片整理，把大量的存活对象给挪在一起，空出来连续内存空间，这个过程还得“Stop the World”，那就更慢了。万一并发清理期间，剩余内存空间不足以存放要进入老年代的对象了，引发了“Concurrent Mode Failure”问题，那更是麻烦，还得立马用“Serial Old”垃圾回收器，“Stop the World”之后慢慢重新来一遍回收的过程，这更是耗时了

G1通过追踪发现，1个Region中的垃圾对象有10MB，回收他们需要耗费1秒钟，另外一个Region中的垃圾对象有20MB，回收他们需要耗费200毫秒，然后在垃圾回收的时候，G1会发现在最近一个时间段内，比如1小时内，垃圾回收已经导致了几百毫秒的系统停顿了，现在又要执行一次垃圾回收，那么必须是回收上图中那个只需要200ms就能回收掉20MB垃圾的Region啊！

所以简单来说，G1可以做到让你来设定垃圾回收对系统的影响，他自己通过把内存拆分为大量小Region，以及追踪每个Region中可以
回收的对象大小和预估时间，最后在垃圾回收的时候，尽量把垃圾回收对系统造成的影响控制在你指定的时间范围内，同时在有限的时
间内尽量回收尽可能多的垃圾对象

Region可能属于新生代也可能属于老年代，所以没有新生代给多少内存老年代给多少内存这一说

因为JVM最多可以有2048个Region，然后Region的大小必须是2的倍数，比如说1MB、2MB、4MB之类的，比如说堆大小是4G，那么就是4096MB，此时除以2048个Region，每个Region的大小就是2MB。大概就是这样子来决定Region的数量和大小的，大家一般保持默认的计算方式就可以

个新生代的参数，“-XX:SurvivorRatio=8”，比如新生代之前说刚开始初始的时候，有100个Region，那么可能80个Region就是Eden，两个Survivor各自占10个Region

随着不停的在新生代的Eden对应的Region中放对象，JVM就会不停的给新生代加入更多的Region，直到新生代占据堆大小的最大比例60%。而且Eden区还占满了对象，这个时候还是会触发新生代的GC，G1就会用之前说过的复制算法来进行垃圾回收，进入一个“Stop the World”状态，然后把Eden对应的Region中的存活对象放入S1对应的Region中，接着回收掉Eden对应的Region中的垃圾对象，但是这个过程跟之前是有区别的，因为G1是可以设定目标GC停顿时间的，也就是G1执行GC的时候最多可以让系统停顿多长时间，可以通过“-XX:MaxGCPauseMills”参数来设定，默认值是200ms。

对象在新生代躲过了很多次的垃圾回收，达到了一定的年龄了，“-XX:MaxTenuringThreshold”参数可以设置这个年龄，他就
会进入老年代

动态年龄判定规则，如果一旦发现某次新生代GC过后，存活对象超过了Survivor的50%

G1提供了专门的Region来存放大对象，而不是让大对象进入老年代的Region中，一个大对象如果太大，可能会横跨多个Region来存放

新生代、老年代在回收的时候，会顺带带着大对象Region一起回收，所以这就是在G1内存模型下对大对象的分配和回收的策略

G1有一个参数，是“-XX:InitiatingHeapOccupancyPercent”，他的默认值是45%，果老年代占据了堆内存的45%的Region的时候，此时就会尝试触发一个新生代+老年代一起回收的混合回收阶段

初始标记

并发标记

最终标记

混合回收

如果在进行Mixed回收的时候，无论是年轻代还是老年代都基于复制算法进行回收，都要把各个Region的存活对象拷贝到别的Region里去，此时万一出现拷贝的过程中发现没有空闲Region可以承载自己的存活对象了，就会触发 一次失败，一旦失败，立马就会切换为停止系统程序，然后采用单线程进行标记、清理和压缩整理，空闲出来一批Region，这个过程是极慢极慢的

G1回收掉300个Region 600MB内存，大致需要200ms

随着系统运行，每秒创建3MB的对象，大概1分钟左右就会塞满100个Region（200MB内存），此时很可能G1会觉得，要是我现在就触发一次新生代gc，那么回收区区200MB只需要大概几十ms，最多就让系统停顿几十ms而已，跟我的主人设定的“-XX:MaxGCPauseMills”参数限制的200ms停顿时间相差甚远，还不如给新生代先增加一些Region，然后让系统继续运行着在新生代Region中分配对象好了，这样就不用过于频繁的触发新生代gc了，然后系统继续运行，一直到可能300个Region都占满了，此时通过计算发现回收这300个Region大概需要200ms，那么可能这个时候就会触发一次新生代gc了

接着你就在浏览器上访问当前这台机器的7000端口号，就可以通过图形化的方式去分析堆内存里的对象分布情况了。

扩容的大小为(len+addlen)*2的大小，
如增加123，避免一直进行扩容，只扩大
，不变小，主要是append命令，当len
长度超过1M的时候，会1M1M的增加

修改数据时，会先修改缓冲池Buffer Pool的值，如果缓冲池中没有值，先从磁盘文件中读取到缓存中，同时对塔加锁，并且把旧值写入到undo日志文件中，方便回滚

5、准备提交事务redo日志刷入磁盘

Dledger是基于Raft协议实现的一个机制

此时一旦Master Broker宕机了，就可以在多个副本，也就是多个Slave中，通过Dledger技术和Raft协议算法进行leader选举，直接将
一个Slave Broker选举为新的Master Broker，然后这个新的Master Broker就可以对外提供服务了，整个过程也许只要10秒或者几十秒的时间

Broker是基于OS操作系统的PageCache和顺序写两个机制

首先Broker是以顺序的方式将消息写入CommitLog磁盘文件的，也就是每次写入就是在文件末尾追加一条数据就可以了，对文件进行
顺序写的性能要比对文件随机写的性能提升很多

另外，数据写入CommitLog文件的时候，其实不是直接写入底层的物理磁盘文件的，而是先进入OS的PageCache内存缓存中，然后后
续由OS的后台线程选一个时间，异步化的将OS PageCache内存缓冲中的数据刷入底层的磁盘文件。

所以在这样的优化之下，采用磁盘文件顺序写+OS PageCache写入+OS异步刷盘的策略，基本上可以让消息写入CommitLog的性能
跟你直接写入内存里是差不多的，所以正是如此，才可以让Broker高吞吐的处理每秒大量的消息写入

问题：异步刷盘实际消息在Broker机器上的os cache中，如果宕机，消息会丢失

发起一轮一轮的投票，通过三台机器互相投票选出来一个人作为Leader，Broker01是投票给自己的，Broker02是投票给自己的，Broker03是投票给自己的，第一轮选举是失败，接着每个人会进入一个随机时间的休眠，比如说Broker01休眠3秒，Broker02休眠5秒，Broker03休眠4秒，此时Broker01必然是先苏醒过来的，他苏醒过来之后，直接会继续尝试投票给自己，并且发送自己的选票给别人，接着Broker03休眠4秒后苏醒过来，他发现Broker01已经发送来了一个选票是投给Broker01自己的，此时他自己因为没投票，所以会尊重别人的选择，就直接把票投给Broker01了，同时把自己的投票发送给别人，此时所有人都会收到三张投票，都是投给Broker01的，那么Broker01就会当选为Leader，其实只要有（3台机器 / 2） + 1个人投票给某个人，就会选举他当Leader，这个（机器数量 / 2） + 1就是大多数的意思

数据同步会分为两个阶段，一个是uncommitted阶段，一个是commited阶段

Leader Broker上的DLedger收到一条数据之后，会标记为uncommitted状态，然后他会通过自己的DLedgerServer组件把这个uncommitted数据发送给Follower Broker的DLedgerServer。接着Follower Broker的DLedgerServer收到uncommitted消息之后，必须返回一个ack给Leader Broker的DLedgerServer，然后如果Leader Broker收到超过半数的Follower Broker返回ack之后，就会将消息标记为committed状态，然后Leader Broker上的DLedgerServer就会发送commited消息给Follower Broker机器的DLedgerServer，让他们也把消息标记为comitted状态

内存预映射机制

文件预热