try-finally 可保证无论是否异常，finally 中代码必执行，适合埋点统计；用 System.nanoTime() 记录起始时间，finally 中计算并上报耗时；结合 ThreadLocal 捕获异常可区分成功/失败耗时；推荐封装为工具方法或 AOP 注解以提升复用性与健壮性。
理解 try-finally 与埋点统计的核心逻辑
在 Java 中，try-finally 能保证无论是否抛出异常，finally 块中的代码一定执行。这恰好契合“执行时长统计”的需求：我们关心的是「这段逻辑实际耗时多少」，不管它成功还是失败。因此，只需在 try 块开始前记录起始时间，在 finally 中计算并上报耗时，就能实现**异常感知、零遗漏**的埋点。
基础实现：手动记录 + finally 上报
最直接的方式是使用 System.nanoTime()（高精度、不受系统时间调整影响）：
- 在 try 前获取起始纳秒时间戳
- 在 finally 中获取结束时间戳，相减得耗时（纳秒），再转为毫秒或微秒
- 将耗时、方法标识、异常信息（如有）一并记录或发送至监控系统
示例代码片段：
long startNanos = System.nanoTime();
try {
doBusiness(); // 业务逻辑
} finally {
long costMs = (System.nanoTime() - startNanos) / 1_000_000;
String methodName = "doBusiness";
Throwable error = null;
// 注意：此处无法直接拿到异常对象，需配合 catch 或 ThreadLocal 捕获
monitor.report(methodName, costMs, error);
}增强健壮性：结合 ThreadLocal 捕获异常信息
单纯用 try-finally 无法在 finally 中访问 try 块抛出的异常对象。若需区分「成功耗时」和「失败耗时」，或记录错误类型，可借助 ThreadLocal 在 catch 中暂存异常，再在 finally 中读取：
立即学习“Java免费学习笔记（深入）”；
- 定义
private static final ThreadLocal<throwable> ERROR_HOLDER = ThreadLocal.withInitial(() -> null);</throwable> - 在 catch 块中调用
ERROR_HOLDER.set(e) - 在 finally 中通过
ERROR_HOLDER.get()获取异常，并在上报后调用ERROR_HOLDER.remove()防止内存泄漏
这样既保持了 finally 的必执行特性，又补全了异常上下文，使监控数据更具诊断价值。
生产可用建议：封装为可复用工具或注解
重复写时间记录模板易出错且侵入业务代码。推荐两种轻量级封装方式：
-
静态工具方法：提供
TimeTrace.start()返回一个AutoCloseable对象，配合 try-with-resources 自动结束并上报 -
简单 AOP 注解（如基于 Spring @Aspect）：对标注了
@Timed的方法自动织入计时逻辑，finally 行为由 AOP 的 afterReturning / afterThrowing + after 统一保障
二者都避免手动管理时间戳和 ThreadLocal，降低误用风险，也便于统一开关、采样率控制、标签打点（如接口名、用户 ID、环境标识）等扩展。
