为何JDK中Thread.sleep和Object.wait的纳秒参数未被精确生效？

这个实现是通用JDK的标准跨平台逻辑，和你当前使用的macOS环境没有特殊绑定，核心原因可以归纳为三点：

• 底层系统的物理精度上限
  包括macOS、Windows、通用Linux发行版在内的绝大多数商用操作系统，本身就不支持纳秒级的线程阻塞唤醒精度。虽然部分系统调用（比如macOS的nanosleep）接口层面接收纳秒单位的参数，但实际唤醒延迟受系统时钟中断周期、线程调度时间片、内核上下文切换开销影响，普通场景下实际误差在微秒到毫秒级。哪怕是服务器级硬件，一次内核态线程切换的开销通常也在1-10微秒区间，根本不可能实现1ns级的精确等待，纳秒级参数从硬件和系统层面就没有落地的基础。
• API契约的兼容性设计
  带纳秒参数的sleep、wait重载方法从JDK早期版本就已存在，当时的主流操作系统甚至连稳定的毫秒级计时精度都无法保证。这两个方法的API契约从来不是“精确等待指定的纳秒时长”，而是保证实际等待时间不短于传入的总时长（毫秒+纳秒）。你看到的“只要纳秒值大于0、且毫秒值未溢出就给毫秒数加1”的逻辑，刚好以最低的代码成本满足了这个契约：无论传入1ns还是999999ns，最终等待时长都不会短于用户指定的时间，最多产生不到1ms的额外等待，完全符合方法的设计约定。
• 细粒度换算无实际收益
  有开发者会疑惑为什么不做更精细的判断——比如纳秒值超过500000（0.5ms）再进位、小于则不进位？本质是因为底层系统的调度误差本身就远大于1ms以内的数值差，做这种精细换算除了增加边界判断的代码复杂度、引入溢出或逻辑bug的风险外，不会带来任何实际的精度提升。

注：只有跑在专用实时操作系统上的实时Java（RTSJ）定制实现，才会真正实现纳秒级的等待精度，普通桌面、服务器场景使用的通用OpenJDK/OracleJDK发行版，都会采用你看到的这套进位逻辑。

内容的提问来源于stack exchange，提问作者Don_Quijote