system.nanotime() 可用于复杂业务计时，但必须精准包裹目标逻辑（如单次数据库查询或风控规则执行），排除日志、锁、i/o、gc、jit等干扰，并通过预热和多轮采样提升准确性。
在复杂业务逻辑中用 System.nanoTime() 计时，关键不是“能不能测”，而是“测到的是否真是你要分析的部分”。它本身精度足够，但业务越复杂，干扰源越多——日志、锁、I/O、对象创建、GC、JIT 编译等都可能混进结果里。必须主动剥离这些噪声，才能让纳秒值反映真实计算开销。
只包裹真正要评估的代码段
不要把整个 run() 或 service 方法头尾套上 nanoTime。起始和结束标记必须紧贴目标逻辑边界，比如一次数据库查询、一段 JSON 反序列化、一个风控规则引擎的执行入口。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- ✅ 正确：在
doRiskCheck(input)调用前记start，调用后立即记end - ❌ 错误：在方法开头初始化参数、打日志、校验字段，这些都不属于“风控逻辑”本体，不该计入耗时
- ⚠️ 注意：如果目标逻辑内部有异步回调或线程切换（如
CompletableFuture），nanoTime 无法跨线程延续，需改用分布式追踪或线程局部记录
避开常见污染源
复杂业务常依赖外部系统或资源，这些等待行为会严重扭曲测量结果：
- 网络请求、文件读写、数据库连接获取 —— 属于 I/O 等待，不是 CPU 计算，应单独隔离测量
-
synchronized块或ReentrantLock.lock()—— 如果测的是算法本身，锁竞争时间应剔除；若测的是并发瓶颈，则需另设计压测场景 - 日志输出（尤其是
log.info("xxx")）、字符串拼接、临时对象创建 —— 可能触发 GC 或占用栈空间，建议测量期间关闭 debug 日志、避免内联字符串 - JIT 编译影响：首次执行含类加载、解释运行、热点编译开销，务必先空跑 10,000 次以上再采集有效样本
批量+多轮采样，降低单次误差
单次 nanoTime 差值容易被调度抢占、TLB miss、缓存未命中等瞬时因素干扰，尤其当业务逻辑本身很短（
- 每轮执行 N 次（例如 10,000 次），统计总耗时再除以 N，得到单次均值
- 重复运行至少 30 轮，取各轮均值的中位数，比平均值更能抵抗毛刺
- 输入数据每次重建（new ArrayList、new byte[]），避免因对象复用导致缓存效应或 GC 干扰
单位换算与结果表达要合理
nanos 是原始单位，直接展示易读性差，转换时要注意精度和用途匹配：
- 算法微基准测试：转微秒（÷1000），保留整数即可，如
durationNs / 1000 - 接口级或流程级耗时：转毫秒（÷1_000_000.0），保留 1–3 位小数，如
String.format("%.3f ms", costNs / 1_000_000.0) - 避免用
Math.round(costNs / 1_000_000)强制取整 —— 可能掩盖亚毫秒级优化效果 - 不把 nanoTime 值存入日志或监控系统做绝对时间比对，它只适合同一 JVM 内的差值运算
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
