jvm

JVM（Java虚拟机）在这里，主要讨论3个方面： 1 JVM内存区域划分2 类加载机制3 垃圾回收机制先来讨论第1个JVM（Java虚拟机）：仿照真实的机器，真实的操作系统，进行设计的

JVM 垃圾回收机制详解：从标记过程、回收算法到垃圾收集器1. 为什么要有垃圾回收？2. JVM垃圾回收过程3 垃圾回收器有哪些典型实现？4. 总结前言：这里是小谢同学整理的JVM相关"如何实现垃圾回收的"相关笔记。笔记用于自我复盘巩固，有错误欢迎大家指出，专栏还有 Java、网络、C 语言等系列笔记欢迎翻阅~同时也希望这篇文章能够帮助到你!

此时不提桶，更待何时

01-04-B-垃圾回收面试与生产事故实战📌 导读：这是《垃圾回收机制详解》的配套 B 篇。GC 是 Java 面试深挖的终点站——从"怎么判断对象死了"一路追问到"ZGC 为什么快"，答不上来就暴露深度。本篇把高频题按追问链一问一答连贯展开，生产事故按场景 → 根因 → 预防 → 解决 → 一句话教训五段式复盘。原理细节标注"见 A 篇 x.x 节"。

【JVM核心体系02】JVM 运行时内存区域：堆、栈、元空间、直接内存一次讲清上一篇我们从整体上建立了 JVM 的知识地图：这一篇开始深入其中最核心的一部分：JVM 运行时内存。很多 JVM 问题最终都会回到内存。

用户09424856803

第12章：JDK 诊断工具箱——jps / jstat / jmap / jcmd / jhsdb业务场景：某物流调度系统的"运单匹配"服务每隔几分钟就会出现 CPU 打到 100%、服务完全无响应的情况，但 10-20 秒后又自动恢复。开发组加了 Prometheus 监控，却因为采集间隔大（15 秒）而完美的"跳过"了每次故障窗口。运维通过 top 看到 CPU 爆表后只能重启，故障原因永远定位不到。

程序员阿鹏

双亲委派机制双亲委派机制简单来说就是类加载的一个顺序机制，简单来说就是：当一个类加载器收到加载请求时，检查该类是否已经被当前加载器加载过。如果已加载，直接返回；若未加载，开始委派，先委托父加载器去加载，父加载器加载不了，才自己加载。

用户09424856803

第11章：OpenJDK反射、动态代理与 MethodHandle 初探业务场景：某微服务团队在 JDK 17 升级过程中遇到了一个诡异的问题——他们的内部 RPC 框架在动态代理工厂中通过反射调用目标方法，升级后所有 setAccessible(true) 调用全部抛出了 InaccessibleObjectException。框架的序列化模块（依赖 Field.set() 注入值）也同样瘫痪。整个微服务集群因一个"反射失败"全线宕机。

纯轻量级锁体系下C2编译器锁粗化和消除机制剖析本文旨在记录近期研读Java源码的学习心得与疑难问题。由于个人理解水平有限，文中内容难免存在疏漏，恳请读者不吝指正。

【java】Java 两种锁机制与线程阻塞唤醒原理—— 从 synchronized / ObjectMonitor 到 ReentrantLock / AQS + futex 全链路解析

java服务异常日志只打印异常类型，没有堆栈定位分析转载请注明出处：在定位一个问题的时候，发现日志只打印了异常的类型，却没有堆栈，对问题定位造成了影响，而且很多时候这个异常页很容易被忽略：

程序员黎剑

JVM-元空间溢出-OutOfMemoryError-Metaspace排查与解决Metaspace 溢出常被误以为是堆不够，其实根因是类加载器泄漏导致类元数据无法卸载。本文讲清 Heap 与 Metaspace 的区别、类卸载机制，以及 jstat / arthas 排查和治理方法。

11路没有终点

Java 微服务性能调优：jstack/jmap/jstat 三剑客实战指南适合人群：Java 微服务测试工程师、SDET、性能调优工程师阅读时长：约 30 分钟在微服务架构中，Java 服务（Spring Boot / Spring Cloud）是最常见的服务实现。当线上出现 CPU 飙高、内存溢出（OOM）、响应变慢、接口超时时，只会看监控图表是远远不够的——你必须能深入 JVM 内部，拿到线程栈、堆内存快照、GC 数据这三把钥匙。

Markword在紧凑对象头上的实现原理剖析本文旨在记录近期研读Java源码的学习心得与疑难问题。由于个人理解水平有限，文中内容难免存在疏漏，恳请读者不吝指正。

Java 27 升级实测：默认值动得比新特性多，有个老参数会让 JVM 直接起不来昨天刷到 JDK 27 GA 的消息（build 35 转正，Mark Reinhold 在邮件列表发的公告），看了眼 JEP 列表：9 个 JEP，4 个 preview 加 1 个 incubator，没什么能上头条的大特性。搁往年这种版本我可能扫一眼就过了，但这回翻 release notes 的时候发现不对劲——这版的默认值动得有点多，对象头、GC、JFR 全都在悄悄换行为。今天把 Linux x64 的 GA 包（jdk.java.net/27，226MB）拉下来跑了一遍，java --ver

用户09424856803

第10章：OpenJDK异常体系、栈轨迹与错误诊断入门业务场景：某金融支付系统在生产高峰时段突然发生宕机——应用进程直接崩溃，留下了两份文件：一个 hs_err_pid12345.log 和一个 core dump。运维紧急重启后，开发组展开了 3 小时的故障复盘。但尴尬的是，团队中没有人能完整读懂 hs_err_pid 日志——它包含了 JVM 崩溃时的完整内存快照、线程堆栈、编译任务、GC 历史等，但大家只在里面搜索"error""crash"等单词，找不到明显的异常信息，最终结论是"不明原因的 JVM 崩溃"。

杨杨杨大侠

Java 不再需要 JVM？一文看懂 GraalVM Native Image、Substrate VM 与 JDK平时我们运行 Java 服务，通常是：但使用 GraalVM Native Image 后，启动命令可能变成：

顺风尿一寸

从 ls -U 到 Tomcat libs加载jar包：ext4 目录哈希序如何影响 Java 文件排序顺序你贴出的源码其实串起了一条完整链路：Java File.list() → glibc readdir → getdents64 系统调用 → VFS iterate_dir → ext4 ext4_readdir。这条链路决定了 ls -U 看到的顺序，也决定了 Tomcat 扫描 lib/WEB-INF/lib 下 jar 时底层枚举到的原始顺序。

Agent最小权限实现：策略表、临时令牌与撤权回归Agent 通过员工账号调用订单接口，只写了一条审批备注。功能测试看似通过，但同一个账号还能导出客户数据和改变审批状态。权限问题不在这次调用做错了，而在运行环境允许它做更多事。

用户09424856803

第9章：OpenJDK堆分代与 Serial/Parallel GC 基础业务场景：某电商的"每日推荐"批处理任务每天凌晨 2 点运行，处理约 2000 万条用户行为数据，计算推荐模型并写入缓存。该任务一直稳定运行在 JDK 8 的 Parallel GC 下，耗时约 45 分钟。团队为了使用虚拟线程特性，将 JDK 升级到 21，JVM 参数原封不动搬过来。结果批处理耗时从 45 分钟飙升至 70 分钟，运维排查发现 GC 停顿时间占比从 3% 变为 18%。