不能用 System.nanoTime() 单独测算“借出连接的物理损耗”，因其本质是软件层开销；需分段测量池内复用路径，满足预热、绑核、禁GC、零锁采样四约束，并剔除GC、调度、TSC偏差污染。
不能用 System.nanoTime() 单独测算“借出连接的物理损耗”——这个词本身在技术语境中不成立。连接借出（如数据库连接池中 getConnection()）是纯内存操作，不涉及物理设备读写；所谓“损耗”实际是线程调度延迟、锁竞争、对象分配、GC 干扰等软件层开销。nanoTime 可测的是这段逻辑的**端到端耗时**，但必须剥离干扰，才能逼近真实开销。
明确测量目标：不是“物理损耗”，而是连接获取延迟
所谓“借出连接”的耗时，本质是连接池实现中的一次同步/异步获取操作，典型路径包括：
- 检查空闲连接队列（可能加锁或 CAS）
- 若无空闲，则触发创建新连接（含 TCP 握手、SSL 协商等真实 I/O）——这部分才涉及网络与系统调用
- 返回连接对象引用（轻量）
因此，要精密测算，必须分段打点：仅对“池内复用”路径计时（排除新建连接），并确保被测逻辑已 JIT 编译、无 GC 暂停污染。
正确使用 nanoTime 的四条硬约束
直接套用 start = nanoTime(); getConnection(); end = nanoTime(); 会严重失真。必须满足：
- 只测池内复用场景：预热连接池，确保所有请求都命中空闲连接（例如 HikariCP 设置
minimumIdle > 0，且并发数 ≤ minimumIdle） - JVM 预热完成：运行至少 10 秒压测，让 JIT 编译稳定，避免首次调用混入 C2 编译耗时
- 绑定 CPU 核心：用
taskset或 JVM 参数（如-XX:+UseThreadPriorities）减少跨核调度抖动 - 禁用非必要 GC：使用 ZGC 或 Shenandoah，并监控
G1EvacuationPause是否发生；一旦检测到 GC，整批样本标记为污染，不参与聚合
采样与统计必须无锁、保尾部
高并发下，频繁 new 对象或 synchronized 会放大测量误差本身。推荐做法：
- 用
ThreadLocal<long[]>维护环形缓冲区（例如 4096 元素），索引用AtomicInteger自增取模，零锁写入 - 每次记录原始纳秒差值（
end - start），不做单位转换，避免除法精度损失 - 每 5 秒 flush 一次缓冲区，聚合时弃用 P1 和 P99.99 外围毛刺，用截尾均值（trim mean）算中心趋势，P95/P99 单独走直方图桶
- 对比基线：在同一环境跑一个空循环（
for(int i=0;i<100;i++);）测 nanoTime 调用自身开销，确认业务逻辑耗时显著高于该基线（例如 >100ns）
识别并剔除三类典型污染
即使满足上述条件，以下情况仍会让结果失效：
-
Stop-The-World GC：Full GC 或 G1 Mixed GC 暂停期间，nanoTime 照常递增，但连接获取逻辑未执行——需通过
GarbageCollectorMXBean实时比对收集次数变化 - 线程抢占：高并发下线程被调度器强制切走，尤其在容器限制 CPU quota 时，单次耗时可能突增至毫秒级——这类样本应归入“调度噪声”，单独标注
-
TSC 同步偏差：多核 CPU 上，不同核心的 TSC 计数器若未严格同步（常见于虚拟机或老旧服务器），跨核调用 nanoTime 可能产生数十纳秒跳变——建议压测时绑定单核或启用
clocksource=tsc tsc=reliable内核参数
