在不改动业务逻辑前提下，用try-catch实现轻量级监控切入，关键在于精准捕获异常、耗时、空值、慢调用、降级点五类可观测信号，通过守门式包裹、try-with-resources封装、异步上报和finally兜底四步低成本织入。
在不改动原有业务逻辑的前提下，用 try-catch 实现轻量级监控切入，关键不是“包住所有代码”，而是“精准捕获可观测信号”——异常、耗时、空值、慢调用、降级点。Java 本身不提供 AOP 或字节码增强能力，但合理利用 try-catch 的语义边界，配合少量辅助工具，就能低成本织入监控埋点。
1. 在关键路径入口加一层“守门式 try-catch”
不修改原方法体，只在调用方（如 Controller、Service 入口、定时任务 run()）包裹一层 try-catch，并记录基础指标：
- 捕获 Throwable（不只是 Exception），避免漏掉 Error 或 OOM 前兆
- 用 System.nanoTime() 计算执行耗时，比 currentTimeMillis() 更精确
- 记录方法名、参数摘要（如 JSON.toJSONString(params, SerializerFeature.WriteClassName) 截断前 200 字）、HTTP 状态码（若适用）
- 示例：Controller 方法外层统一拦截，不侵入 service 层，却能拿到完整链路耗时与失败归因
2. 用 try-with-resources 封装可监控资源
将监控上下文包装成 AutoCloseable 资源，靠 JVM 自动释放机制触发上报：
- 写一个 MonitorSpan 类，构造时 startTimer()，close() 时 finish() 并发往 MetricsRegistry 或日志
- 在旧方法开头写 try (MonitorSpan span = new MonitorSpan("order.create")) { ... } —— 不改逻辑，只增一行
- 即使中间 return、break、throw，close() 仍会执行，保证耗时统计不丢
- 比裸 try-catch 更简洁，且天然支持嵌套（子 Span 可继承父上下文 traceId）
3. catch 中做“非阻塞式异步上报”
避免监控逻辑拖慢主流程，尤其不能在 catch 里同步调远程接口或写磁盘：
- 用 Disruptor、BlockingQueue 或 Spring 的 ApplicationEventPublisher 异步投递监控事件
- catch 块里只做轻量操作：log.warn("xxx failed", e); eventPublisher.publishEvent(new ErrorEvent(method, e));
- 确保监控组件自身有熔断（如连续失败 10 次自动禁用该埋点），防止雪崩
- 这样既保留了错误现场，又不污染原有事务边界和响应时间
4. 利用 finally 做“兜底状态快照”
有些问题不抛异常但结果异常（如返回 null、空集合、status=500 却没 throw），可在 finally 中检查返回值并采样：
- 定义局部变量 result，在 try 块末尾赋值；finally 中 if (result == null) monitor.recordNullReturn(methodName)
- 对 List 类型，可 if (result != null && result.isEmpty()) monitor.recordEmptyResult(...)
- 注意：仅适用于返回值明确、生命周期可控的场景（如非流式响应、非 CompletableFuture）
- 这类“静默异常”往往比显式异常更难定位，恰恰是监控盲区
不复杂但容易忽略：try-catch 不是监控的终点，而是信号采集的起点。真正价值在于把捕获到的信息，以低开销、可聚合、带上下文的方式送出去——日志打点、Micrometer 指标、OpenTelemetry Span、甚至只是内存计数器+定时 dump，都可以成为切入点。核心原则就一条：不动旧逻辑，只在边界加“传感器”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
