如何排查线上问题
cpu 偏高问题排查
数据库问题排查
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2017-12-24
client 与 server
client 模式 默认的jit编译器，c1。 默认的gc：serial-serial old。 需要更短的启动时间和初始堆大小，能做更保守的优化。 默认-Xms是1M，-Xmx是64M。 适合 GUI 程序。 server 模式 默认的jit编译器，c2。 默认的gc：ps-serial old即 PS MarkSweep（可以启用parallel old）。 需要更长的启动时间和更大的堆大小，能够做更有深度的优化。 默认-Xms是128M，-Xmx是1024M。 适合长时间运转的程序。 64 位JVM# 在64位 JVM 上有个 -d64 的模式，实际上就是禁止client模式单独启动，只允许server模式或者混合编译模式启动的模式。
2026-02-07
G1/ZGC/Shenandoah 垃圾收集器对比
垃圾收集的核心挑战 垃圾收集器的设计始终面临三个核心指标的权衡：吞吐量、延迟和内存占用。这三个指标构成了一个不可能三角，优化其中一个指标往往需要牺牲其他指标。 吞吐量指单位时间内完成的工作量，通常用应用程序运行时间占总时间的比例来衡量。对于批处理任务、科学计算等场景，高吞吐量是首要目标。 延迟指垃圾收集造成的应用停顿时间。对于交互式应用、金融交易系统等对响应时间敏感的场景，低延迟至关重要。延迟通常关注最大停顿时间和停顿时间分布。 内存占用指垃圾收集器为了完成收集工作所需的额外内存空间。内存受限的环境下，收集器自身的内存开销成为关键约束。 传统垃圾收集器在三者之间做出明确取舍：Serial 和 Parallel GC 追求高吞吐量，但停顿时间较长；CMS GC 降低停顿时间，但牺牲吞吐量并占用更多内存。现代收集器试图在三者之间找到更优的平衡点。 G1（Garbage First）收集器 G1 收集器在 JDK 7u4 版本正式推出，是 JDK 9 之后的默认垃圾收集器。G1 的核心思想是打破传统分代收集的物理隔离，将堆内存划分为多个大小相等的 Region。 Region 化堆内存...
2026-02-07
JVM 的内存模型与线程
JVM 的内存模型与线程 Java 内存模型（Java Memory Model, JMM）定义了多线程环境下共享变量的访问规则，是理解并发编程的基石。本文从硬件架构出发，逐步深入到 JMM 的核心机制与实践模式。 模式总览 # 模式名称 一句话口诀 适用场景 1 写刷读清 写入即刷盘，读取先清空 volatile / unlock 后的可见性 2 顺序锁 同把锁内，串行执行 synchronized 临界区保护 3 偏序传递 A先于B，B先于C，则A先于C happens-before 链式推理 4 不可变安全 构造完成前不逃逸，完成后不修改 final 字段的安全发布 一、从硬件到抽象：为什么需要 JMM 1.1 CPU 架构的性能鸿沟 现代 CPU 的处理速度远超主内存（DRAM）的响应能力。以 Intel Skylake 架构为例： 层级 典型延迟 容量范围 L1 Cache ~4 cycles 32KB L2 Cache ~12 cycles 256KB L3 Cache ~40 cycles 8-32MB ...
2026-01-12
Java 并发编程笔记
本文思维导图总览： 下载思维导图源文件 写在前面的话 并发编程最早的实践都在操作系统里。高层语言的并发模型都要基于底层系统对硬件抽象和并发的设计来设计和实现，不能超出操作系统允许的范围。所谓的高级抽象总体上是简化对 OS 底层机制的复杂调用。 并发与异步 本文聚焦并发（Concurrency），即多任务在同一时间段内的交替或并行执行，核心问题是资源共享、线程同步与协作。 **异步（Asynchronous）**是另一维度：调用方发起操作后不等结果返回即继续执行，通过回调、Future或事件机制获取结果。异步可通过单线程事件循环实现，也可依托多线程并发实现。 二者关系：并发关注"多任务如何执行与协调"，异步关注"调用是否阻塞等待"。并发编程常涉及异步，但本文不展开异步编程模式（如响应式流、协程），相关内容请参阅《Java 线程池笔记》。 管程 理论和实践之间是有鸿沟的，要弥合这种鸿沟，通常需要我们去学习别人的实践。比如并发的标准设计思想来自于操作系统里的管程（monitor），我们应当学习管程，进而了解标准的并发模型-管理共享变量和线程（并...
2026-04-19
Java栈帧省略机制详解：为什么异常堆栈会消失？
引言：诡异的异常堆栈消失现象 线上服务报错时，你打开日志准备排查问题，却发现异常堆栈信息神秘消失了： 1java.lang.NullPointerException 只有短短一行异常类名，没有完整的堆栈跟踪。你可能会怀疑：是日志框架出问题了？还是被什么拦截器截断了？ 其实，这是 JVM 的一个性能优化机制，叫做 OmitStackTraceInFastThrow（快速抛出时省略堆栈跟踪）。从 JDK 5 开始引入，默认启用。 本文将深入剖析这个机制的设计动机、工作原理、触发条件，以及如何正确应对。 一、问题场景：异常堆栈去哪了？ 1.1 复现现象 用一段简单的代码就能复现： 123456789101112public class ExceptionOmitDemo { public static void main(String[] args) { String msg = null; for (int i = 0; i < 500000; i++) { try { ...
2017-10-23
昂贵的异常
抛出问题 Joshua Bloch 在《Effective Java》的 Item 57 里明确地提到过，不要试图用 Exception 的跳转来代替正常的程序控制流。他列举了很多原因，但特别提到了抛出异常会使得整个程序运行变慢。抛出异常远比普通的 return、break 等操作对控制流、数据流的性能影响要大，它就只适合拿来作异常分支的控制语句，而不能拿来编写正常的逻辑。 Throwing exception is expensive. 这句话在 Java 的程序员世界里面已经成为老生常谈，却很少有人谈及到底抛出异常比正常的程序跳转返回慢在哪里，有多慢。"不要滥用异常"好像一个猴子定律，人们知道不能这么做，却不明白为什么不能这么做。 此前读了一位同事写的好文《Java虚拟机是如何处理异常的》，深入地分析了 JVM 对异常跳转的处理过程：JVM 会通过异常表的机制，优化异常抛出和正常返回之间的性能差异。仅从程序计数器的移动上来讲，抛出一个异常对栈帧的弹栈并不比直接返回更昂贵。写在前头的结论是："try-catch 语句块几乎不会影响程序运行性能！...