dev*_*ull 283 java multithreading exception-handling interrupted-exception
以下处理方式有什么区别InterruptedException
?最好的方法是什么?
try{
//...
} catch(InterruptedException e) {
Thread.currentThread().interrupt();
}
Run Code Online (Sandbox Code Playgroud)
要么
try{
//...
} catch(InterruptedException e) {
throw new RuntimeException(e);
}
Run Code Online (Sandbox Code Playgroud)
编辑:我也想知道这两个使用的场景.
aio*_*obe 401
你可能会问这个问题,因为你已经调用了一个抛出的方法InterruptedException
.
首先,您应该看到throws InterruptedException
它是什么:方法签名的一部分以及调用您正在调用的方法的可能结果.因此,首先要接受一个事实,InterruptedException
即a是方法调用的完全有效的结果.
现在,如果您正在调用的方法抛出此类异常,您的方法应该怎么做?您可以通过考虑以下问题找出答案:
你正在实施的方法是否有意义InterruptedException
?换句话说,InterruptedException
调用你的方法是一个明智的结果?
如果是,那么throws InterruptedException
应当成为你的方法签名,你应该让异常传播(即不抓住它的话).
示例:您的方法等待来自网络的值以完成计算并返回结果.如果阻塞网络调用抛出
InterruptedException
您的方法无法以正常方式完成计算.你让InterruptedException
传播.Run Code Online (Sandbox Code Playgroud)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
如果无法计算总和,则打印" "是可接受的(并且比由于a使程序因堆栈跟踪而崩溃要好得多InterruptedException
).换句话说,用这个方法声明这个方法是没有意义的throws InterruptedException
.Run Code Online (Sandbox Code Playgroud)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
:您正在尝试读取文件,规范说您应该尝试10次,间隔1秒.你打电话Thread.sleep(1000)
.所以,你需要处理InterruptedException
.对于一种方法tryToReadFile
来说,如果说"如果我被打断了,我就无法完成尝试阅读文件的行为"这样的方法非常有意义.换句话说,它对抛出的方法非常有意义InterruptedExceptions
.Run Code Online (Sandbox Code Playgroud)String tryToReadFile(File f) throws InterruptedException { for (int i = 0; i < 10; i++) { if (f.exists()) return readFile(f); Thread.sleep(1000); } return null; }
该帖子已被改写为一篇文章在这里.
mR_*_*r0g 91
碰巧在今天早上我正在阅读Brian Goetz的Java Concurrency In Practice工作方式.基本上他说你应该做两件事之一
传播InterruptedException
- 声明您的方法抛出已检查的内容,InterruptedException
以便您的调用者必须处理它.
恢复中断 - 有时候你不能扔掉InterruptedException
.在这些情况下,您应该InterruptedException
通过调用interrupt()
方法来捕获并恢复中断状态,currentThread
以便调用堆栈上方的代码可以看到发出了中断.
Gro*_*uez 18
你想做什么?
在InterruptedException
抛出时,一个线程正在等待或睡眠,而另一个线程使用中断它interrupt
在类方法Thread
.因此,如果您捕获此异常,则表示该线程已被中断.通常没有必要Thread.currentThread().interrupt();
再次调用,除非你想从其他地方检查线程的"中断"状态.
关于你投掷a的其他选择RuntimeException
,这似乎不是一件非常明智的事情(谁会抓住这个?它将如何处理?)但是如果没有其他信息就很难说清楚.
Nat*_*hes 12
对我来说,关键是关键是:InterruptedException不会出错,它是线程做你告诉它做的事情.因此,重新抛出它包含在RuntimeException中是没有意义的.
在许多情况下,当你说,我不知道这里出了什么问题而且我无法做任何事情来修复它时,重新抛出包含在RuntimeException中的异常是有意义的,我只是想让它摆脱当前的处理流程并点击我拥有的任何应用程序范围的异常处理程序,以便它可以记录它.这不是InterruptedException的情况,它只是响应于调用了interrupt()的线程,它抛出InterruptedException以帮助及时取消线程的处理.
因此传播InterruptedException,或者智能地使用它(意味着它将完成它本来要做的地方)并重置中断标志.注意,当抛出InterruptedException时,中断标志被清除; Jdk库开发人员的假设是捕获异常等于处理它,因此默认情况下标志被清除.
所以肯定第一种方式更好,问题中第二个发布的示例没有用,除非你不希望线程实际上被中断,并且中断它等于错误.
这是我写的一个答案,用一个例子来描述中断是如何工作的.您可以在示例代码中看到它使用InterruptedException来保存Runnable的run方法中的while循环.
正确的默认选择是将InterruptedException添加到throws列表中.中断表示另一个线程希望您的线程结束.这个请求的原因并不明显,完全是上下文的,所以如果你没有任何额外的知识,你应该假设它只是一个友好的关闭,任何避免关闭的都是一个非友好的响应.
Java不会随机抛出InterruptedException,所有建议都不会影响你的应用程序,但我遇到了开发人员遵循"吞下"策略变得非常不方便的情况.一个团队开发了大量测试并使用了Thread.Sleep.现在我们开始在CI服务器中运行测试,有时由于代码中的缺陷会陷入永久等待.为了使情况更糟,当尝试取消CI作业时,它从未关闭,因为旨在中止测试的Thread.Interrupt并未中止作业.我们必须登录到该框并手动终止进程.
总而言之,如果您只是抛出InterruptedException,那么您将匹配线程应该结束的默认意图.如果你不能将InterruptedException添加到你的throw列表中,我会把它包装在RuntimeException中.
有一个非常合理的论据是InterruptedException本身应该是RuntimeException,因为这会鼓励更好的"默认"处理.它不是RuntimeException,只是因为设计者坚持使用RuntimeException应该代表代码中的错误的分类规则.由于InterruptedException不会直接来自代码中的错误,因此不会.但实际情况是,通常会出现InterruptedException,因为代码中存在错误(即无限循环,死锁),而Interrupt是处理该错误的其他线程的方法.
如果你知道有理性的清理要做,那就去做吧.如果您知道中断的更深层原因,您可以采取更全面的处理方式.
总而言之,您的处理选择应遵循以下列表:
我只是想在大多数人和文章提到的内容中添加最后一个选项。正如 mR_fr0g 所说,通过以下方式正确处理中断很重要:
传播中断异常
在线程上恢复中断状态
或者另外:
根据您的情况以自定义方式处理中断并没有错。由于中断是终止请求,而不是强制命令,因此完成额外工作以允许应用程序优雅地处理请求是完全有效的。例如,如果一个线程正在休眠,等待 IO 或硬件响应,当它收到中断时,那么在终止线程之前优雅地关闭任何连接是完全有效的。
我强烈建议您理解该主题,但这篇文章是一个很好的信息来源:http : //www.ibm.com/developerworks/java/library/j-jtp05236/
归档时间: |
|
查看次数: |
152670 次 |
最近记录: |