java中的多线程中断异常处理

htrmnn0y  于 2021-06-27  发布在  Java
关注(0)|答案(6)|浏览(395)

以下处理方法有什么区别 InterruptedException ? 最好的方法是什么?

try{
 //...
} catch(InterruptedException e) { 
   Thread.currentThread().interrupt(); 
}

try{
 //...
} catch(InterruptedException e) {
   throw new RuntimeException(e);
}

编辑:我还想知道这两种方法在哪些场景中使用。

rekjcdws

rekjcdws1#

你想干什么?
这个 InterruptedException 当一个线程正在等待或休眠,而另一个线程使用 interrupt 类中的方法 Thread . 因此,如果捕捉到此异常,则表示线程已被中断。通常打电话是没有意义的 Thread.currentThread().interrupt(); 同样,除非您想从其他地方检查线程的“中断”状态。
关于你的另一个选择 RuntimeException ,这似乎不是一件非常明智的事情(谁会抓住这个?如何处理?)但如果没有额外的信息,很难说出更多的信息。

bfhwhh0e

bfhwhh0e2#

正确的默认选择是将interruptedexception添加到抛出列表。中断表示另一个线程希望您的线程结束。这个请求的原因并不明显,完全是上下文关系,所以如果你没有任何额外的知识,你应该假设这只是一个友好的关闭,任何避免关闭的都是一个非友好的响应。
java不会随机抛出interruptedexception,所有的建议都不会影响您的应用程序,但我遇到了一个开发人员遵循“吞咽”策略变得非常不方便的情况。一个团队开发了大量的测试,并经常使用thread.sleep。现在我们开始在ci服务器上运行测试,有时由于代码中的缺陷会陷入永久性等待。更糟糕的是,在尝试取消ci作业时,它从未关闭,因为用于中止测试的thread.interrupt没有中止作业。我们必须登录到这个框并手动终止进程。
长话短说,如果您只是抛出interruptedexception,那么您就是在匹配线程应该结束的默认意图。如果您不能将interruptedexception添加到抛出列表中,我会将其 Package 为runtimeexception。
有一个非常合理的论点是interruptedexception本身应该是runtimeexception,因为这将鼓励更好的“默认”处理。它不是runtimeexception,只是因为设计者坚持一个分类规则,即runtimeexception应该表示代码中的错误。因为interruptedexception不是直接由代码中的错误引起的,所以它不是。但实际情况是,经常会出现中断异常,因为代码中有错误(即无止境循环、死锁),而中断是其他线程处理该错误的方法。
如果你知道有合理的清理工作要做,那就去做吧。如果你知道中断的深层原因,你可以采取更全面的处理。
总之,您的处理选择应遵循以下列表:
默认情况下,添加到throws。
如果不允许添加到throws,则抛出runtimeexception(e)(多个坏选项的最佳选择)
只有当您知道中断的明确原因时,才能根据需要进行处理。如果您的处理是本地方法,则通过调用thread.currentthread().interrupt()来中断重置。

ui7jx7zq

ui7jx7zq3#

以下处理中断异常的方法有什么区别?最好的方法是什么?
您可能会问这个问题,因为您调用了一个抛出 InterruptedException .
首先,你应该看看 throws InterruptedException 它是什么:方法签名的一部分和调用所调用方法的可能结果。所以从接受一个事实开始 InterruptedException 是方法调用的完全有效的结果。
现在,如果您调用的方法抛出这样的异常,您的方法应该怎么做?你可以通过思考以下问题来找出答案:
您正在实现的方法抛出 InterruptedException ? 换言之,是一个 InterruptedException 调用方法时的合理结果?
如果是,那么 throws InterruptedException 应该是方法签名的一部分,并且应该让异常传播(即根本不捕获它)。
示例:您的方法等待来自网络的值来完成计算并返回结果。如果阻塞网络调用抛出 InterruptedException 你的方法不能以正常的方式完成计算。你让他 InterruptedException 传播。

int computeSum(Server server) throws InterruptedException {
    // Any InterruptedException thrown below is propagated
    int a = server.getValueA();
    int b = server.getValueB();
    return a + b;
}

如果否,则不应使用 throws InterruptedException 你应该(必须!)捕捉异常。在这种情况下,有两点很重要:
有人打断了你的话。可能有人急于取消操作,优雅地终止程序,或者其他什么。你应该对那个人彬彬有礼,不用再多管闲事就从你的方法中归来。
即使您的方法能够在 InterruptedException 线程被中断的事实可能仍然很重要。特别是,调用方法的代码可能对方法执行期间是否发生中断感兴趣。因此,您应该通过设置中断标志来记录发生中断的事实: Thread.currentThread().interrupt() 示例:用户要求打印两个值的总和。“打印” Failed to compute sum 如果无法计算和,则可以接受(这比让程序在堆栈跟踪中由于错误而崩溃要好得多) InterruptedException ). 换句话说,用 throws InterruptedException .

void printSum(Server server) {
     try {
         int sum = computeSum(server);
         System.out.println("Sum: " + sum);
     } catch (InterruptedException e) {
         Thread.currentThread().interrupt();  // set interrupt flag
         System.out.println("Failed to compute sum");
     }
}

现在应该很清楚 throw new RuntimeException(e) 是个坏主意。对打电话的人不太礼貌。您可以创建一个新的运行时异常,但根本原因(有人希望线程停止执行)可能会丢失。
其他示例:
实施 Runnable :您可能已经发现 Runnable.run 不允许重新起动 InterruptedExceptions . 好吧,你报名了 Runnable ,也就是说你注册了 InterruptedExceptions . 或者选择不同的接口,例如 Callable ,或遵循上述第二种方法。
 
打电话 Thread.sleep :您正在尝试读取一个文件,规范要求您应该在间隔1秒的时间内尝试10次。你打电话来 Thread.sleep(1000) . 所以,你需要处理 InterruptedException . 对于一种方法,例如 tryToReadFile 说“如果我被打断了,我就无法完成读取文件的操作”是非常有意义的。换句话说,这个方法抛出 InterruptedExceptions .

String tryToReadFile(File f) throws InterruptedException {
    for (int i = 0; i < 10; i++) {
        if (f.exists())
            return readFile(f);
        Thread.sleep(1000);
    }
    return null;
}

这篇文章在这里被改写成了一篇文章。

gr8qqesn

gr8qqesn4#

我只想在大多数人和文章提到的问题上添加最后一个选项。正如\u fr0g先生所说,通过以下方式正确处理中断是很重要的:
传播中断异常
恢复线程上的中断状态
或者另外:
中断的自定义处理
根据您的情况,以自定义方式处理中断没有什么错。由于中断是一种终止请求,而不是强制命令,因此完成额外的工作以允许应用程序优雅地处理请求是完全有效的。例如,如果一个线程正在休眠,等待io或硬件响应,当它接收到中断时,那么在终止线程之前,完全可以优雅地关闭任何连接。
我强烈建议理解这个主题,但这篇文章很有意思

gj3fmq9x

gj3fmq9x5#

对我来说,关键的一点是:interruptedexception并不是出了什么问题,而是线程按照你的命令去做。因此,在runtimeexception中重新调用它是没有意义的。
在许多情况下,重新抛出一个 Package 在runtimeexception中的异常是有意义的,当你说,我不知道这里出了什么问题,我也不能做任何事情来修复它,我只想让它退出当前的处理流程,并点击我所有的应用程序范围的异常处理程序,这样它就可以记录它。interruptedexception不是这样的,它只是线程响应interrupt()的调用,它抛出interruptedexception是为了帮助及时取消线程的处理。
所以传播interruptedexception,或者聪明地吃掉它(意味着在一个地方,它将完成它的本意),并重置中断标志。注意,当抛出interruptedexception时,中断标志被清除;jdk库开发人员的假设是捕捉异常相当于处理异常,因此默认情况下清除该标志。
因此,第一种方法肯定更好,问题中的第二个示例没有用,除非您不希望线程实际被中断,并且中断它相当于一个错误。
下面是我写的一个例子,描述了中断是如何工作的。您可以在示例代码中看到,它使用interruptedexception跳出runnable的run方法中的while循环。

yqkkidmi

yqkkidmi6#

碰巧我今天早上在去实践java并发的路上读到了brian goetz的文章。基本上他说你应该做三件事中的一件
传播 InterruptedException -声明方法以抛出选中的 InterruptedException 所以打电话的人必须处理。
恢复中断-有时你不能抛出 InterruptedException . 在这种情况下,你应该抓住 InterruptedException 并通过调用 interrupt() 上的方法 currentThread 因此,调用堆栈上层的代码可以看到发出了中断,并从方法中快速返回。注意:这仅适用于方法具有“try”或“best effort”语义的情况,即。e。如果这个方法不能完成它的目标,那么就不会发生任何关键的事情。例如, log() 或者 sendMetric() 可能是这样的方法,或者 boolean tryTransferMoney() ,但不是 void transferMoney() . 请参阅此处了解更多详细信息。
忽略方法中的中断,但在退出-e时恢复状态。g。via guava's餐厅 Uninterruptibles . Uninterruptibles 接管样板代码,如jcip中的不可取消任务示例§ 7.1.3.

相关问题