如何排查线上问题
cpu 偏高问题排查
数据库问题排查
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2019-10-23
进程和操作系统的诊断工具
系统变慢时，先区分 CPU 忙、任务在等待、内存紧张、磁盘空间不足，还是网络连接异常。不同工具观察的是不同层次：top 展示资源概况，ps 定位进程与线程，ss 观察套接字，strace 跟踪系统调用。单个指标只能缩小范围，需要同一时间窗口内的其他证据支撑判断。 本文面向 Linux，主要采用 procps-ng、GNU coreutils、iproute2 的命令格式。macOS 的选项和字段不同，也没有 Linux 的 /proc 接口；精简容器可能缺少部分命令。示例中的 PID 12466、端口 8080 和路径 /var/log 均需替换为实际目标。输出字段随工具版本变化，应以本机 man 为准。 从现象选择排查入口 先记录时间、目标 PID、进程启动时间和所在容器，再连续采样。快照适合确认“现在是什么”，区间统计适合回答“这几秒发生了什么”。进程重启后 PID 可能复用，不能把重启前后的数据直接拼起来。 图 1：从系统现象逐步定位到进程证据。 flowchart TD accTitle: 从系统现象到进程证据的排查路径 A["延迟升高或服务异常...
2026-10-08
Kotlin 03：函数参数和返回值怎样约束任务输入
taskProposal("alpha") 没有传重试次数，究竟用了什么值？如果改成 taskProposal(" ", retries = 6)，调用方得到 null，还是抛出异常？参数列表和返回类型把这些问题分开了：省略实参有缺省规则，空白内容可以没有预览结果，非法的重试配置则必须被拒绝。 沿用 02 的命令解析器，本篇给同一个合成任务系统增加一个尚未接入 CLI 的输入预览函数。它只返回格式化文本，没有任务实体、队列、执行器或持久化；函数名中的 proposal 也不表示已经提交。实验环境仍是 Kotlin 2.2.21、Gradle 8.14、JDK 21。 省略参数与显式覆盖是不同的调用 核心函数的公开契约很短： 1234567fun taskProposal(text: String, retries: Int = 2, vararg labels: String): String? { if (retries !in 0..5) rejectRetries(retries) require(labels...
2020-03-08
JMX 深度历险
JMX 常见指标 JVM 指标 系统指标 System 相关指标 描述 system.load.average 系统load，如果是docker，此指标收集的物理机的load cpu.system.load.percent 系统所有进程占用cpu的百分比 cpu.jvm.load.percent jvm占用cpu的百分比 system.process.used.phyical.memory 系统使用的物理内存 system.process.used.swap.size 系统使用的swap内存 JVM 内存指标 JVM相关指标 描述 jvm.gc.count GC的次数 jvm.gc.time GC的时间，单位毫秒 jvm.younggc.count 年轻代GC的次数 ，包括的GC算法（Copy，ParNew，PS Scavenge，G1 Young Generation） jvm.younggc.time 年轻代GC的时间，单位毫秒 jvm.fullgc.count 年老代GC的次数，包括的GC算法 jvm.f...
2026-05-21
进程启动期的静默故障：JVM 与 Node.js 的调试方法论
很多人都遇到过这种场景：一个 JVM 进程因为 -Xmx 写错了一个字符，启动起来就死掉，控制台一行日志都没有；一个 Node.js CLI 比如 opencode 在前台 hang 住，光标不闪，也不退出；一个 Spring Boot 服务被 systemd 拉起来，systemctl status 显示 running，但端口永远不开。stderr 看不到、源码也没有，只能反复重启。 这类问题的共同点不是程序"出 bug"，而是进程在"出第一行日志"之前就已经失败或卡住。常规的"看日志找异常"那一套这时候没东西可看。需要的是另一类方法论：把进程当黑盒，从外部撬开它的状态。 一、先把"看不到日志"分成四种情况 把"启动期黑盒"展开来看，至少是四种性质完全不同的故障。混在一起调，方向就错了。 类别 特征 进程状态 主要工具方向 A. crash 静默 进程已经退出，但没看到任何 stderr 不存在 找输出去向；看 OS / runtime 留下的尸检文件 B....
2026-01-19
线程安全与锁优化
版本说明：本文主要基于 JDK 6 ~ JDK 14 的 HotSpot 虚拟机实现。需要注意的是，从 JDK 15 开始，偏向锁已被默认关闭并标记为废弃（JEP 374）。如果你使用的是 JDK 15+，文中关于偏向锁的内容仅作为历史参考。 线程安全 什么是线程安全 “当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方法进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那么这个对象就是线程安全的。” 相对的线程安全，可以分成五个等级。但在深入讨论线程安全的分类之前，我们需要先理解 Java 内存模型——它是理解线程安全问题的理论基础。 Java 内存模型基础 Java 内存模型（Java Memory Model，JMM）是 Java 语言规范的一部分，定义了多线程程序中共享变量的访问规则。理解 JMM 是理解线程安全问题的基础。 为什么需要内存模型？ 现代计算机系统中，CPU 与主内存之间存在巨大的速度差异。为了弥补这一差距，硬件层面引入了多级缓存（L1、L2、L3 Cache）。这带来了一个问...
2026-02-07
G1/ZGC/Shenandoah 垃圾收集器对比
垃圾收集的核心挑战 垃圾收集器的设计始终面临三个核心指标的权衡：吞吐量、延迟和内存占用。这三个指标构成了一个不可能三角，优化其中一个指标往往需要牺牲其他指标。 吞吐量指单位时间内完成的工作量，通常用应用程序运行时间占总时间的比例来衡量。对于批处理任务、科学计算等场景，高吞吐量是首要目标。 延迟指垃圾收集造成的应用停顿时间。对于交互式应用、金融交易系统等对响应时间敏感的场景，低延迟至关重要。延迟通常关注最大停顿时间和停顿时间分布。 内存占用指垃圾收集器为了完成收集工作所需的额外内存空间。内存受限的环境下，收集器自身的内存开销成为关键约束。 传统垃圾收集器在三者之间做出明确取舍：Serial 和 Parallel GC 追求高吞吐量，但停顿时间较长；CMS GC 降低停顿时间，但牺牲吞吐量并占用更多内存。现代收集器试图在三者之间找到更优的平衡点。 G1（Garbage First）收集器 G1 收集器在 JDK 7u4 版本正式推出，是 JDK 9 之后的默认垃圾收集器。G1 的核心思想是打破传统分代收集的物理隔离，将堆内存划分为多个大小相等的 Region。 Region 化堆内存...