封装Thread.sleep的try/catch为sleep()方法是否可行？存在哪些问题？

结论 #

这种封装逻辑本身是可行的，但你给出的示例写法存在严重隐患，不能直接在生产环境使用。

示例写法的核心问题 #

• 线程中断状态被吞，中断机制完全失效
  Thread.sleep抛出InterruptedException时会自动清除当前线程的中断标记，示例中仅捕获异常打印堆栈，既没有重新设置中断状态，也没有向上抛出异常，上层代码完全感知不到线程曾被中断。如果上层业务原本是通过中断机制通知线程终止任务，这种写法会直接导致任务无法正常停止，出现逻辑异常。
• 灵活性极差，无法适配多场景需求
  示例直接把sleep时长写死为1000ms，不同业务需要不同等待时长时完全无法复用。就算改造成入参传时长，固定的catch逻辑也适配不了不同业务对中断的处理诉求：部分场景需要中断后立即终止任务、部分场景需要清理资源后退出、部分场景需要忽略中断继续重试，固定死的打印逻辑完全覆盖不了这些需求。
• 问题排查效率极低
  生产环境中e.printStackTrace()的输出基本不会被采集到统一日志系统中，而且日志里没有任何业务上下文信息，出现中断异常时根本无法定位是哪块业务逻辑触发的sleep，排查问题成本极高。

合理的封装方案 #

如果确实需要封装sleep逻辑来简化代码、统一管理，可以选用以下两种方案：

方案1：不吞中断，保留上层感知能力 #

private void sleep(long millis) {
    try {
        Thread.sleep(millis);
    } catch (InterruptedException e) {
        // 重新设置线程中断标记，让上层可以感知到中断事件
        Thread.currentThread().interrupt();
        // 用统一日志框架输出带上下文的异常信息，方便排查
        log.warn("线程休眠被中断，当前线程名：{}", Thread.currentThread().getName(), e);
    }
}

方案2：不捕获异常，交给上层业务自行处理 #

private void sleep(long millis) throws InterruptedException {
    Thread.sleep(millis);
}

这种封装看起来只是简化了类名前缀，但后续如果要统一替换休眠实现（比如换成TimeUnit.MILLISECONDS.sleep()、加休眠时长监控、调试时统一修改休眠时长等），只需要改这一处即可，维护成本很低。

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