主题
界面
主题
工具不是越多越好,而是「够用 + 会用」 —— 链接列表在 项目与工具索引,本节给的是「最小必需工具链」与选择原则 ✓✓。
★ 一条主线:从「开发」到「诊断」到「验证」的三段工具链 ✓✓:
开发:JDK 21 + Maven(Wrapper) + IDEA + Git
诊断:jcmd / jstack / jmap(JDK 自带)+ Arthas(在线诊断)+ GC 日志
验证:JUnit 5 + Mockito + REST Assured + Selenium + JMeter
★ 原则:**先用 JDK 自带的,再上第三方;每个工具都要能说出「什么时候用它」** ✓✓✓★ 工具链的两种失衡 ✗✗:
| 失衡 | 代价 |
|---|---|
| 工具饥渴(每个新工具都装)✗✗ | 学一堆半吊子,关键时刻一个都不熟 |
| 工具匮乏(只用 IDE 的点按钮)✗✗ | 线上问题无法定位(IDE 连不上生产)✓✓ |
| 段 | 工具 | 什么时候用 |
|---|---|---|
| 开发 | JDK 21(LTS)+ Maven Wrapper + IDEA + Git ✓ | 日常编码与协作 |
| 诊断 | jps / jcmd / jstack(JDK 自带)✓✓ | 线上第一响应(无依赖、最稳) |
| Arthas ✓✓✓ | 需要看方法内部(trace/watch/jad)时 | |
GC 日志(-Xlog:gc*)✓✓ | 内存与停顿问题 | |
jmap / -XX:+HeapDumpOnOutOfMemoryError ✓ | 保留 OOM 现场 | |
| 验证 | JUnit 5 + Mockito ✓✓ | 单元测试 |
| REST Assured ✓ | 接口测试 | |
| Selenium + 驱动 ✓ | UI 自动化(本机 Edge 驱动需与主版本一致) | |
| JMeter ✓ | 压测与拐点定位 | |
| 构建/交付 | Docker ✓ | 环境一致性 |
| CI 流水线(三条:docs / java / coverage)✓ | 质量门禁 |
★★ 顺序原则 ✓✓✓:先用 JDK 自带的,再上第三方 —— jps → jcmd 能解决 60% 的线上问题;Arthas 解决剩下的深度问题 ✓✓(《Arthas 与线上问题诊断》 的实测顺序)。
对每个你「会用」的工具,回答:
① 它解决什么问题?(一句话)✓
② 什么时候用它、什么时候**不用**它?✓✓(边界)
③ 用它的成本是什么?(开销 / 依赖 / 权限)✓✓✓★ 示例(Arthas) ✓✓:① 在线诊断(无需重启);② 需要看方法内部时用,只看看线程/堆就别上它; ③ 增强有开销(trace 高流量方法必须限额)、需要授权 ✓。
| 原则 | 说明 |
|---|---|
| 必要性优先 ✓✓ | 没有明确场景的工具不装(装了就忘) |
| 可替代性 ✓ | 优先选「团队已有 + 生态成熟」的(避免孤岛工具) |
| 可观测自身 ✓✓ | 工具自己要能"被排障"(有日志、有版本、可回滚) |
① JDK 版本:编译 --release 21(基线),本机可跑更高版本 —— 但**行为差异要验证** ✓✓
② 浏览器驱动:驱动必须与本机浏览器主版本一致(Edge 驱动从国内镜像取)✗✗
★ 两个坑都在本知识库的规则文件里有记录(.codebuddy/rules)✓✓✓① jps 找到进程 → ② jcmd Thread.print 看线程与死锁
→ ③ 不够深才上 Arthas(thread/trace/watch)→ ④ 内存问题加 GC 日志与 heap dump
★ 顺序 = 成本从低到高 ✓✓✓装 APM、装探针、装火焰图 ✗✗(还没定位就先付开销与复杂度)
正解:**先用零成本工具缩小范围,再针对性上工具** ✓✓✓| # | 错误 | 说明 |
|---|---|---|
| 1 | 工具饥渴 ✗✗ | 装了不用等于没有 ✓✓ |
| 2 | 只会 IDE 点按钮 ✗✗ | 线上(无 IDE)无从下手 ✓✓ |
| 3 | 忽略 JDK 自带工具 ✗✗ | 零依赖、最稳的第一响应 ✓✓✓ |
| 4 | 不记版本与驱动对齐 ✗✗ | 反复踩同一个坑 ✓ |
| 5 | 不知道工具开销 ✗ | 诊断本身压垮服务 ✓✓ |
验收方式:能说出三段工具链的各 2-3 个工具,并为每个说出使用场景与替代方案。
SX 资源索引区到此完成 —— 全库 214 个知识点全部有页面 ✓✓✓ 继续:学习路线总览 | 知识覆盖矩阵 | 《环境与工具链》
无,可直接开始
暂无