1 调优原则 多数导致GC问题的Java应⽤，都不是因为我们参数设置错误，⽽是代码问题； 实际使用中，分析GC优化代码，比优化JVM参数效果要好，JVM 参数的默认（推荐）值都是经过 JVM 团队的反复测试和前人的充分验证得出的比较合理的值，因此通常来说是比较靠谱和通用的，一般不会出大问题。 如果满足下面的指标，则一般不需要进行GC： Minor GC执行时间不到50ms，不低于10秒一次；

ZGC收集器(-XX:+UseZGC)ZGC是一款JDK 11中新加入的具有实验性质的低延迟垃圾收集器。JDK 11只支持linux系统，JDK 14才支持了macOs和Windows系统 一 特点1. 支持TB量级的堆。这应该可以满足未来十年内，所有JAVA应用的需求了 吧。 2. 最大GC停顿时间不超10ms。 目前一般线上环境运行良好的JAVA应用Minor GC停顿时间在10ms左右，

G1收集器(-XX:+UseG1GC)G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多核处理器及大容量内存的机器. 满足可预测的停顿时间停顿时间的同时,还具备高吞吐量性能特征. 一 特点1. 分代收集 虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念 G1将Java堆划分为多个大小相等的独立区域（Region），一般Region

1 垃圾收集算法1.1 标记 - 清除算法算法分为“标记”和“清除”两个阶段:首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。缺点:（1）效率问题， 标记和清除两个过程的效率都不高；（2）空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存面不得不提前触发另一次垃圾收集动作。 1.2 标记 - 整

对象内存分配策略 JVM通过逃逸分析确定该对象不会被外部访问。如果不会逃逸可以将该对象在栈上分配内存 大多数情况下，对象在新生代中 Eden 区分配。 大对象直接进入老年代 长期存活的对象将进入老年代 对象动态年龄判断 老年代空间分配担保机制 对象栈上分配概念 我们通过JVM内存分配可以知道JAVA中的对象都是在堆上进行分配，当对象没有被引用的时候，需要依靠GC进行回收内存，如果对象数量较多的

JVM内存参数设置JVM参数设置格式Spring Boot程序的JVM参数设置格式(Tomcat启动直接加在bin目录下catalina.sh文件里)： 1java ‐Xms2048M ‐Xmx2048M ‐Xmn1024M ‐Xss512K ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐jar microservice‐eureka‐serv

JVM内存模型JVM内存模型总体来说分为五大块。分别是：java堆，方法区（1.8后叫元空间）虚拟机栈，本地方法栈，以及程序计数器。 1 堆java堆是java虚拟机所管理的内存中最大的一块。它用来存放对象实例和数组。 在 Java 中，堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old )， 1.8之前还包括方法区。新生代 ( Young ) 又被划分为三个区域：Ede

Jmap命令jmap是一个多功能的命令。它可以生成 java 程序的 dump 文件， 也可以查看堆内对象示例的统计信息、查看 ClassLoader 的信息以及 finalizer 队列。 系统中内存飙升了，怎么办？ 使用jmap看看是否有大量类生成 - histo查看堆内存信息，实例个数以及占用内存大小 命令： ~ jmap -histo 91656 > ./log.txt 结果

Kafka如何保证消息的可靠性？哪些环节会有丢消息的可能？RabbitMQ的消息零丢失方案 - 楼上有只喵 (pyr9.github.io) Kafka怎么保证消息可靠性?1. 生产者保证消息正确发送到Kafka?Kafka通过配置request.required.acks属性来确认消息的生产： 0 生产者将数据发送出去就不管了，不去等待任何返回。这种情况下数据传输效率最高，但是数据可靠性确是最

RabbitMQ的高级特性如何保证消息的顺序？消息的顺序是指的是，一个组内消息的顺序，而不是整个mq里的消息顺序。比如一个下单过程需要完成扣款，减库存，通知快递发货，这一组消息的顺序不能乱。 发送端：一组有序消息，只发到一个队列中，利用队列的FIFO特性保证消息在发送时顺序不会乱。 如果发送端配置了重试机制，就可能出现发送方发送时是1，2，3，但1发送失败，重试发送1，这样收到的消息就是2，3，