嘿，这个问题我当初啃《Java并发编程实战》的时候也卡过一会儿，咱们来一步步把它捋明白～

先把书中的核心代码贴出来方便对照：

public static void timedRun(Runnable r, long timeout, TimeUnit unit) throws InterruptedException {
    Future<?> task = taskExec.submit(r);
    try {
        task.get(timeout, unit);
    } catch (TimeoutException e) {
        // task will be cancelled below
    } catch (ExecutionException e) {
        // exception thrown in task: rethrow
        throw launderThrowable(e.getCause());
    } finally {
        // Harmless if task already completed
        task.cancel(true); // interrupt if running
    }
}

首先得澄清一个关键误解：这两个InterruptedException根本不是发生在同一个线程上的，也不是我们“需要”它们，而是代码逻辑和Java中断机制共同导致的场景，咱们拆解开看：

• 第一个InterruptedException：发生在调用timedRun方法的线程上。
  比如你在主线程里调用timedRun，主线程会卡在task.get()处等待任务结果。如果此时有其他线程给主线程发送中断信号，主线程的get()就会抛出这个异常，意思是“我被打断了，没法继续等任务结果了”。

• 进入finally块后，我们调用task.cancel(true)：这个操作是给执行你传入的Runnable的线程池工作线程发送中断信号，目的是及时终止这个已经不需要的任务——既然调用线程已经因为中断/超时等原因不需要结果了，还让工作线程继续跑就是浪费资源。

那书里提到的“另一个InterruptedException”是怎么回事？
如果你的Runnable代码没有正确响应中断（比如它完全忽略线程的中断标志，自顾自循环执行，或者没有在中断后终止线程），那工作线程被cancel(true)发送中断信号后，可能还会继续运行。这时候，如果工作线程后续执行到Thread.sleep()、Object.wait()这类可中断的方法，或者调用了其他会响应中断的API，这个工作线程就会抛出InterruptedException。这个异常会被Future封装起来，要是之后还有别的代码调用这个Future的get()方法，就会抛出ExecutionException，其底层的cause就是这个工作线程抛出的InterruptedException——书里简化描述成了“throw another InterruptedException”，其实是指这个被封装的异常。

你疑惑的“为什么需要两个InterruptedException”，本质上是混淆了两个独立的中断事件：
第一个是调用线程被中断的信号，第二个是工作线程被中断后抛出的信号，它们服务于不同的场景，不是我们主动要生成两个异常，而是Java并发模型里中断机制的必然结果——每个线程的中断都是独立的协作事件，彼此互不影响。

内容来源于stack exchange