问题标签 [interrupted-exception]

Java的Thread.sleep什么时候抛出InterruptedException？忽略它是否安全？我没有做任何多线程。我只想等待几秒钟，然后重试某些操作。

当队列中没有任何内容并调用 take() 时，究竟会发生什么。API 说该方法将等待，但这是否意味着 CPU 会旋转检查是否为空/非空，直到有项目在队列中，或者是否意味着线程产生并会被中断唤醒？如果是前者，我可能想看看队列是否为空，以及是否调用 thread.yield() 以放弃处理器时间。我的问题是我真的需要调用 yield 还是一些内部机制为我处理？

其次，中断异常是什么意思？如果我理解正确，这意味着如果线程 A 正在执行此方法并且正在等待输入并且另一个线程 B 调用 threadA.interrupt() 那么线程 A 将捕获中断的异常并可能暂停执行，如果它很好的话。这是正确的思考方式吗？

在 Effective Java（第 275 页）中，有以下代码段：

捕获中断的异常只是为了重新引发它有什么用？为什么不让它飞呢？

让我们假设我有一个线程消耗另一个线程产生的项目。它的run方法如下，inQueue为BlockingQueue

此外，一个不同的线程将通过中断这个正在运行的线程来发出没有​​更多工作项的信号。如果不需要阻塞来检索下一个工作项，则 take() 将抛出一个中断的异常。即，如果生产者表示它已完成填充工作队列，是否有可能不小心将某些项目留在 inQueue 中或错过中断？

以下程序演示了该问题（最新的 JVM 和其他）：

我了解 InterruptedException 的作用以及抛出它的原因。但是，在我的应用程序中，我在等待SwingUtilities.invokeAndWait()仅由我的应用程序知道的线程时得到它，并且我的应用程序从不调用Thread.interrupt()任何线程，它也从不将线程的引用传递给任何人。

所以我的问题是：谁打断了我的线程？

有没有办法告诉？InterruptedException 不包含请求中断的线程的名称是否有原因？

我读到它可能是执行此操作的框架或库，我们使用以下内容，但我想不出他们中断我的线程的原因：

• 休眠
• 春天
• 日志4J
• Mysql 连接器

我的代码片段：

我应该如何处理代码中的InterruptedExceptionand ExecutionException？

在什么情况下会抛出这些异常？

我有一个长时间运行的过程，由于错误，一个琐碎/可消耗的线程与我想继续的线程死锁，以便它可以执行一些难以以另一种方式重现的最终报告。

当然，为以后的运行修复错误是正确的最终解决方案。当然，任何线程的任何此类强制中断/终止/停止本质上都是不安全的，并且可能导致其他不可预知的不一致。（我熟悉所有标准警告及其原因。）

但是，由于唯一的选择是终止 JVM 进程并经历一个更冗长的过程，这将导致最终报告不太完整，因此混乱/弃用/危险/有风险/一次性技术正是我想要的尝试。

JVM 是 Ubuntu 上 Sun 的 1.6.0_16 64 位，消耗线程正在等待锁定对象监视器。

定向到确切线程的 OS 信号能否在可消耗线程中创建 InterruptedException？

附加gdb，直接篡改JVM数据或调用JVM过程，是否可以强制释放消耗线程持有的对象监视器？

Thread.interrupt()来自另一个线程的 a会InterruptedException从等待锁定帧中生成 a 吗？（通过一些努力，我可以将任意 beanshell 脚本注入到正在运行的系统中。）

Thread.stop()是否可以通过 JMX 或任何其他远程注入方法发送已弃用的？

任何想法表示赞赏，越“危险”越好！而且，如果您的建议在类似情况下的个人经验中起作用，那就最好了！

我有一个主程序，它在目标设备（智能手机）上运行脚本，并在等待标准输出消息的 while 循环中。然而，在这种特殊情况下，标准输出上的一些心跳消息可能相隔近 45 秒到 1 分钟。

就像是：

所以，我希望能够在从标准输出读取行后启动一个新的可中断线程，并且需要一个睡眠窗口。在能够读取新行后，我希望能够中断/停止（无法终止进程），处理标准输出文本的换行并重新启动进程。

如果我无法在计时器窗口中读取一行（比如 45 秒），我也想找到一种方法来摆脱我的 while 循环。

我已经尝试过 thread.run，thread.interrupt 方法。但是在杀死和启动新线程时遇到了麻烦。

这是最好的出路还是我错过了一些明显的东西？

我最近将我的计算机更新为功能更强大的计算机，配备四核超线程处理器 (i7)，因此可以提供大量真正的并发性。现在，在退出（ ）我正在开发的应用程序（带有 Swing GUI）时，我偶尔会遇到以下错误：System.exit(0)

好吧，鉴于它开始发生在具有更高并发能力的硬件上，并且与线程有关，而且偶尔会发生，这显然是某种时间问题。但问题是堆栈跟踪太短了。我只有上面的清单。它根本不包含我自己的代码，因此很难猜测错误在哪里。

有没有人经历过这样的事情？任何想法如何开始解决它？

编辑：由于退出 Swing 应用程序System.exit(0)可能是“不干净的”，但我不想将主框架设置为，EXIT_ON_CLOSE因为我想确保应用程序退出时没有任何关键的事情发生，我添加了一个机制以便它执行dispose()调用前主框架的方法System.exit(0)。所以现在应该很干净了，但偶尔还是会发生异常。它发生在System.exit(0)被调用之后；dispose()工作没有问题。也就是说，它必须来自关闭挂钩：

我什至尝试Window通过循环遍历Window.getWindows()数组（它包含无主Dialogs 等）来显式处理所有 s，但它没有任何区别。这个问题似乎与“清洁度”（即在退出前显式释放原生屏幕资源）关系不大。这是另一回事，但什么？

编辑2：将默认关闭操作设置为EXIT_ON_CLOSE没有区别。http://www.google.com/search?q=sun.java2d.Disposer.run(Disposer.java:125)发现了一些错误报告，所以也许这确实是 Sun 的 Java2D 实现中的错误。我可以想象这样的错误可能会在很长一段时间内无法修复，因为它们在实践中是无害的；关闭挂钩的异常几乎不会伤害其他任何人。鉴于这发生在 GUI 应用程序中，除非将stderr其定向到控制台或日志，否则甚至不会注意到异常。