问题：一个只在生产出现的接口变慢 九月下旬，客服反馈"订单详情页打开很慢"。我在测试环境怎么点都是 80ms，生产上就是 3 秒左右。 按以前的办法，要么加日志重新发版（生产发一次要走流程，至少半小时），要么 jstack 抓线程栈（只能看某一瞬间的状态，看不到耗时分布）。这次我试了下 Arthas
为什么要从 CMS 迁到 G1 我们在 JDK 8 上跑 CMS 跑了两年多，一直相安无事。真正推动迁移的是两件事。 第一件是碎片问题终于爆了。四月份的一个凌晨，promotion failed 触发了 Serial Old 单线程 Full GC，整个应用 STW 了 11.4 秒： 2020-0
七个服务七套 JVM 参数，我整理了一份模板 4 月底盘了一遍生产上 7 个微服务的启动参数，发现全是复制粘贴来的，来源各不相同： user-service: -Xms512m -Xmx2g order-service: -Xms4g -Xmx4g -Xmn2g -XX:+UseG1GC
面试官问"你们生产用哪个收集器"，我答不上来 11 月中旬的一次面试，面试官问："你们生产 JVM 用的什么垃圾收集器？为什么选它？" 我当时的回答是"默认的，没配过"。面试官点了点头没追问，但我知道这题挂了。回去之后把 GC 这块从头看了一遍，顺便把我们线上的 GC 日志翻出来分析了下，发现确实该
上线时那个 NoSuchMethodError：两个 jar 里有同一个类 8 月底发版，新功能上线后立刻报了一堆错： 2019-08-27 20:14:32.881 ERROR [http-nio-8080-exec-3] c.x.web.ExceptionHandler - Handler
MAT 里那个 12 万的 java.lang.ref.Finalizer 8 月初排查一个服务的老年代增长，dump 下来用 MAT 打开，Dominator Tree 里第三名是 java.lang.ref.Finalizer，12.4 万个实例，占了 210 MB。我当时看不懂这是个什么类，点
运维在群里 @ 我：你们这个服务内存一直在涨 那天下午运维丢了一张图到群里，是 Zabbix 上我们订单服务的 JVM 内存曲线，从早上 9 点的 1.2 GB 一路爬到下午 4 点的 3.8 GB，容器限制是 4 GB。他问：这是不是内存泄漏？ 我当时的第一反应是想 dump 下来看，被带我的师兄
深入理解 JVM 垃圾回收机制 Java 虚拟机（JVM）的垃圾回收（GC）是内存管理的核心机制。了解 GC 的工作原理对于编写高性能 Java 应用至关重要。 常见的垃圾收集器 Serial GC 单线程，适用于客户端模式 使用 -XX:+UseSerialGC 参数启用 Parallel GC
凌晨三点的告警：Metaspace OOM 3 月 15 号凌晨 3 点 12 分，监控告警把值班同学叫起来了：报表服务的一台实例 Full GC 频繁，接口全部超时。我早上到公司看日志，第一行就是： java.lang.OutOfMemoryError: Metaspace at java
入职第三个月，我把线上服务搞 OOM 了 那是个导出报表的功能。测试环境数据量小，跑得飞快；上线之后运营点了一次"导出全部"，三分钟后服务就挂了。监控上堆内存是一条 45 度的斜线，直接顶到天花板然后掉底。 我登机器捞日志，看到了人生中第一个这个： Exception in thread "http
