加油，努力，认真

JVM内存布局规定了Java在运行过程中内存申请、分配、管理的策略，保证了JVM的稳定高效运行。不同的JVM对于内存的划分方式和管理机制存在部分差异。结合JVM虚拟机规范，一起来探讨jVM的内存布局。如下图所示：Heap堆区是Java发生OOM（Out Of Memory）故障的地方，堆中存储着我们平时创建的实例对象，最终这些不再使用的对象会被垃圾收集器回收掉，而且堆是线程共享的。一般情况下，堆所占用的内存空间是JVM内存区域中最大的，我们在平时编码中，创建对象如果不加以克制，内存空间也会被耗尽。堆的内存

目录1. 说明2. 源码3. 软引用回收时机4. 淘汰策略处理源码5. 可能导致的问题1. 说明以前学习各个引用类型的区别,最近在看一个JVM参数-XX:SoftRefLRUPolicyMSPerMB 对软引用有更深入的了解2. 源码public class SoftReference<T> extends Reference<T> { /** * 由垃圾回收器负责更新的时间戳 */ static private long clock;

目录1. 说明2. 排查步骤3. 一些误区1. 说明测试环境出现非常慢,测试说执行过工单word导出就出现这种问题2. 排查步骤1.查看机器cpu和内存 正常2.排查gc回收 发现一只在触发full gcjstat -gc 10755 3.dump堆信息进行分析jmap -dump:format=b,file=/Users/liqiang/Desktop/logs/heap.hprof pid4.先通过Vm查看根据大对象名字看不出什么问题5.使用MAT 导入dump文件进行分析

目录1. 说明2. 排查1. 说明线上出现异常，但是查看节点状态正常，因为使用了容器,挂掉了会重启。因为jvm配置了-XX：HeapDumpOnOutOfMemoryError 参数，出现OMM就会将当时线程和jvm内存情况转存起来可参考:《JVM参数配置》2. 排查1.将运维发过来的hprof导入到 vm 可参考《JVM监控》2.我们去当时的线程日志查看3.搜索13219这个线程id找到线程查看堆栈信息4.分析堆栈找到业务代码 分析问题原因具体看标红处 发现是导入功能问题 导致oo

目录1. 线程状态可参考2. 问题3. 排查分析3.1. dump jstack日志4. 日志分析1. 线程状态可参考https://www.cnblogs.com/LQBlog/p/15268773.html2. 问题测试环境dubbo服务出现问题，一直刷警告日志,前端反应各个功能模块很慢,看日志是dubbo线程池满了,但是测试环境没有压力2021-09-14 09:32:07,957 WARN [New I/O server worker #1-9] com.alibaba.dubbo.com

目录1. 说明2. 分析3. 针对form和to没按8:1:1配置4. 针对刚上线堆大小设置1. 说明线上内存告警占用了90%+ 订单服务占用了42% 8.3g,分析订单服务是否可以降低配置。2. 分析1.查看应用实际占用内存cat /proc/{pid}/status2.查看jvm启动参数3. 查看高峰期的时候jvm内存增长率jstat -gcutil {pid} 1000 500 1000:1秒采集一次 500:采集500次结论:eden区108秒会触发回收一次，每次

目录1. 说明2. 代码模拟3. AB压测模拟4. 分析5. 分析dump *.hprof文件工具5.1. visualVM5.2. MAT5.3. 在线分析工具6. OQL语法例子7. 异常情况解决方式1. 说明一般我们发现内存持续增长,但是并没有得到释放,我们就需要排查是否内存泄露2. 代码模拟通过ThreadLocal模拟内存泄露为什么ThreadLocal会内存泄露？参考：《ThreadLocal》@RequestMapping("/testController")@Controlle

目录1. 内存监控2. GC 性能衡量指标2.1. 吞吐量2.2. 停顿时间2.3. 垃圾回收频率3. GC 调优策略3.1 降低 Minor GC 频率3.2 降低 Full GC 的频率3.3. 选择合适的 GC 回收器4. 对象在堆中的生命周期5. 查看jvm默认配置6. 查看程序jvm配置7. 具体调优方法1. 内存监控参考:《JVM学习-内存监控(五)》2. GC 性能衡量指标2.1. 吞吐量这里的吞吐量是指应用程序所花费的时间和系统总运行时间的比值。我们可以按照这个公式来计算 GC 的

目录1. 内存监控1.1. -XX:+PrintGC1.2. -verbose:gc1.3. XX:+DisableExplicitGC1.4. -XX:MaxTenuringThreshold1.5. -XX:+PrintGCDetails1.6. -XX:+PrintGCTimeStamps1.7. -XX:+TraceClassLoading1.8. -XX:+PrintClassHistogram1.9. -XX:+PrintHeapAtGC1.10. -Xloggc1.11. -XX:+

目录1. 类编译加载执行过程2. 编译的空间开销2.1. C1 编译器2.2. C2 编译器2.3. 分层编译3. 为何HotSpot虚拟机要实现两个不同的即时编译器？4. 热点探测4.1. 方法调用计数器4.2. 回边计数器5. 编译优化技术5.1. 方法内联5.2. 逃逸分析5.2.1. 栈上分配5.3. 锁消除5.4. 标量替换1. 类编译加载执行过程先将java文件编译为class文件,再由类加载器加载到jvm。类在调用执行过程中，执行引擎会把字节码转为机器码，然后在操作系统中才能执行。在字节

目录1. jstat1.1. 类加载统计1.2. 编译统计1.3. gc统计1.4. 堆内分配统计1.5. 新生代gc和内存情况统计1.6. 老年代gc和内存情况统计1.7. 老年代内存统计1.8. jdk1.7永久代统计1.9. JDK8 下 元数据空间统计1.10. 内存使用百分比2. jstack2.1. 统计线程数量2.2. 高CPU占用排查3. JMAP3.1. 查看jvm配置以及内存信息3.2. dump内存信息3.3. 查看存活对象情况3.4. 查看正在等待执行finalizer方法的对象4.

目录1. 查看当前机器所使用的垃圾回收器2. jvm回收流程3. jvm的几种垃圾回收器4. 常用搭配组合5. 并行，并发，吞吐量？6. serial收集器6.1. 特点6.2. 参数配置7. ParNew7.1. 特点7.2. 参数配置7.3. 流程图8. ParallelScavenge收集器8.1. 特点8.2. 参数配置8.3. 流程图9. Serial Old 收集器9.1. 特点10. Parallel Old 收集器10.1. 流程图11. CMS收集器11.1. 特点11.2. 缺点11.3

目录1. 如何判断一个对象是否能被回收1.1. 引用计数法1.2. 可达性算法2. 判断一个对象生存还是死亡3. 如何回收方法区4. jdk1.2后引用概念5. GC算法5.1. 标记清除法5.2. 标记压缩法5.3. 复制算法1. 如何判断一个对象是否能被回收1.1. 引用计数法比较古老的一种垃圾回收算法。在java的GC并没有采用增加一个引用 引用+1 减少一个引用引用减一每次清除引用为0的的对象缺点：不能回收循环引用的垃圾对象1.2. 可达性算法GC Roots 是该算法的基础，G

目录深入探讨Java类加载器类加载器基本概念java.lang.ClassLoader 类介绍类加载器的树状组织结构类加载器的代理模式(双亲委派模型)加载类的过程线程上下文类加载器Class.forName自定义类加载器的实现深入探讨Java类加载器类加载器是 Java 语言的一个创新，也是 Java 语言流行的重要原因之一。它使得 Java 类可以被动态加载到 Java 虚拟机中并执行。类加载器从 JDK 1.0 就出现了，最初是为了满足 Java Applet 的需要而开发出来的。Java Appl

目录总结总结JVM内存模型内存区域存放的内容程序计数器指令地址Java虚拟机栈操作栈、局部变量表、基本类型、对象引用、返回地址本地方法栈本地方法操作栈Java堆对象实例、数组方法区类信息（类的版本、字段、方法描述信息、接口描述信息）、常量、静态变量、编译后的代码方法区中还有个运行时常量池编译器生成的字面量、符号引用、翻译出来的直接引用JVM内存模型各区域可能发生的异常情况-程序计数器Java虚拟机栈本地方法栈

Tomcat热部署机制对于Java应用程序来说，热部署就是在运行时更新Java类文件。在基于Java的应用服务器实现热部署的过程中，类装入器扮演着重要的角色。大多数基于Java的应用服务器，包括EJB服务器和Servlet容器，都支持热部署。类装入器不能重新装入一个已经装入的类，但只要使用一个新的类装入器实例，就可以将类再次装入一个正在运行的应用程序。我们知道，现在大多数的web服务器都支持热部署，而对于热部署的实现机制，网上讲的却不够完善，下面我们就Tomcat的热部署实现机制，讲解一下它是如何实现的

类加载

JVM内存中各个区域功能及存放内容