我继承的代码是一个服务器,它产生许多不同类型的守护线程,这些线程在请求进入时接收和响应。显然,这很危险,需要重构。就像现在一样,如果主程序在其中一个守护进程正在为请求提供服务时停止,则线程可能会在请求中途被终止,并使某些东西处于不一致的状态。
但是,有很多线程分布在代码的不同区域。如果在调用关闭时我必须手动关闭每个线程,那么在不遗漏一些晦涩的守护进程的情况下获得完美的逻辑流程可能会有点痛苦。
我想做的是拥有一个类似于守护线程的线程,但我可以将线程的某些部分标记或切换为关键部分;这将完成从收割到完成的therad。当守护进程阻塞并等待请求时,它的行为就像一个守护线程,不会阻止虚拟机关闭,如果虚拟机关闭,它将立即停止。但是,当线程主动为特定请求提供服务时(线程处于活动状态的时间的一小部分),线程不会被杀死,直到它完成并退出它的关键部分。一旦线程完成它的关键部分,它就有资格被杀死。理想情况下,当没有更多的非守护线程可用时,VM 会立即启动它的关闭进程,即使某些守护进程仍在做关键工作,通过获取任何不处于关键状态的守护进程,然后等待每个剩余的“守护进程”退出这是关键点,所以它可能会被杀死。
有没有一种简单的方法来获得这种行为,只需实例化一个线程类(可能是我写的)或设置一个布尔值,而不是必须显式地编写每个线程来正确处理中断以表现得像这样?我正在寻找一种最愚蠢的证明方式,这样如果在这样的线程中运行的插件没有被编写为完美地处理中断,那么线程仍将正确地完成它的关键部分,然后在 VM 关闭时退出。