Java中的响应式批处理答案

【问题标题】：Responsive batch processing in JavaJava中的响应式批处理
【发布时间】：2016-05-13 13:07:48
【问题描述】：

我喜欢线程可以共享一些资源但它们最终需要释放其私有资源的事实。同时，一些计算可能已经过时，你使用任务管理器杀死它们。我正在寻找在一个 JVM 进程中完成的相同操作。

你说thread.stop is unreliable 和propose that my thread polls the interrupted flag instead。但是，轮询效率不高，对吧？您既不希望性能损失也不希望无处不在的if (interrupted) 块污染您的代码。这里最合适的选择是什么？

【问题讨论】：

你能证明轮询是低效的吗？还是你只是假设它是？
如果你认为在任何地方插入check(flag) 是有效的，我假设它。
我倾向于衡量而不是假设。它带来了更好的结果。当然也不需要到处检查，只要你做 I/O 或睡眠/等待，就会自动检查标志。如果你不做这些，它仍然是你想要停止的响应速度和你想要检查标志的次数之间的简单权衡。（通常线程停止的速度有多快并不重要，因此每个主循环检查一次就足够了。）
我不明白为什么所有操作系统供应商都迁移到preemptive multitasking，如果我错了，cooperative multitasking 很棒。
我认为您有点混淆了概念。抢先式多任务处理与信令是完全不同的概念，信令是大多数操作系统用来停止进程的。那么，在您的特定情况下，您的基准在哪里显示轮询效率低得无法接受？

【解决方案1】：

在由多个交互进程组成的应用程序中杀死一个进程可能很危险，但它通常不像杀死一个线程那样危险。

一个进程依赖于另一个进程状态的方式通常更为有限。如果进程仅通过网络通信进行交互，那么设计一个可以从其中一个进程被终止后优雅地恢复的应用程序可能并不难。同样，如果进程通过共享事务数据库进行交互。

如果进程通过共享文件进行交互，则更难安全地处理 KILL。如果进程通过共享内存进行交互，那么保证任意 KILL 的安全性几乎是不可能的。

线程总是通过共享内存进行交互。无法处理的 KILL 可能在任何时间出现。没有办法保证杀死某个线程不会使整个程序处于损坏状态。

这就是为什么 t.stop() 在 Java 中被弃用的原因。 真正的问题应该是，“他们为什么首先实施t.stop()？”

【讨论】：