(首先,这是一般性的描述,可以说我没有注意到问题的具体细节。跳到结尾部分,那里讨论了问题中涉及的技术规范。)
没有好的技术原因。这部分是关于人类限制和混乱的API设计。
首先考虑应用程序开发人员的优先事项是创建解决业务问题的工作代码。在赶工期的过程中,彻底学习这样的低级API会被忽略。
其次,在学习东西时,有一个倾向就是达到足够好的状态就不再深入学习了。像线程和异常处理之类的主题往往被忽视。中断是线程书籍中的后面的主题。
现在想象一个由多个人使用的代码库,他们的技能水平和注意力不同,可能会忘记从wait和sleep抛出InterruptedException会重置中断标志,或者interrupted不等于isInterrupted,或者InterruptedIoException也会重置中断标志。如果您有一个finally块捕获IOException,您可能会忽略InterruptedException是IOException的子类,因此可能无法恢复中断标志。可能是匆忙的人决定放弃它,我不能依靠这个中断标志。
这样做对吗?不是的。
由于使用期望中断的工具,但由于难以管理的技术问题而没有信心标志值,将导致出现此类代码。
(抱怨结束,现在实际回答特定的技术规范示例)
好的,看看这篇技术指南文章。有三件事引人注目:
1)除了缩短睡眠时间之外,它根本没有利用中断。然后它只是压制异常,不费力恢复标志或检查它。您可以使用InterruptedException通过在while循环外捕获它来终止,但这不是这个示例所做的。这似乎是一种奇怪的方式。
2)随着示例的完善,清楚地表明正在使用标志来打开和关闭等待。有人可能会使用中断来做到这一点,但这不是惯用法。因此,在这里使用标志是可以的。
3) 这是技术指南中的一个玩具示例。并非所有Oracle内容都像技术规范或API文档一样权威。有些教程存在错误陈述或不完整的情况。可能编写代码的原因是作者认为读者对中断如何工作并不熟悉,最好尽量减少使用。技术撰稿人已知会做出这样的选择。
如果我重写此示例以使用中断,则仍将保留标志; 我将使用中断来终止,并使用标志实现挂起/恢复功能。