容器中Java耗时线程终止实现疑问及方案咨询

package com.example.demo;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.Map;

@RestController
public class RestApi {
    HashMap<String,Thread> threadsWithName = new HashMap();

    @GetMapping("/{someId}")
    public String getThreadName(@PathVariable(value = "someId") final String id) {
        Thread thread = Thread.currentThread();
        String threadName = thread.getName();
        threadsWithName.put(id,thread);
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            threadsWithName.remove(id);
        }
        threadsWithName.remove(id);
        return threadName + " has executed";
    }

    @GetMapping("/runningThreads")
    public ArrayList runningThreads(){
        ArrayList threadnames = new ArrayList();
        for(Map.Entry thread:threadsWithName.entrySet()){
            threadnames.add(thread.getKey());
        }
        return threadnames;
    }

    @GetMapping("/killThreadWithId/{someId}")
    public String killThreadWithId(@PathVariable(value = "someId") final String id){
        Thread thread = threadsWithName.get(id);
        String getName = thread.getName();
        thread.interrupt();
        threadsWithName.remove(id);
        return getName + " killed active count : "+ Thread.activeCount();
    }

    @GetMapping("/activecount")
    public int killThreadWithId(){
        return Thread.activeCount();
    }
}

1. 将Thread对象存入HashMap的做法是否合理？ #

这种做法存在严重问题，完全不合理，核心问题如下：

• 线程安全漏洞：HashMap是非线程安全容器，并发读写时会出现数据错乱、死循环等异常，必须替换为ConcurrentHashMap这类线程安全实现。
• 容器线程违规操作：代码中存储的是Spring MVC的请求线程（属于Web容器线程池），这类线程由容器统一管理，手动中断会破坏线程池的正常复用逻辑，导致后续请求处理异常。
• 内存泄漏风险：线程正常结束或中断异常未触发移除逻辑时，Thread对象会被Map持续持有，无法被GC回收，长期运行会引发内存泄漏。
• 状态不一致问题：仅在Thread.sleep()触发中断时移除记录，若线程执行其他不响应中断的任务，Map中的记录会与实际线程状态脱节。

2. 多容器环境下如何实现线程终止功能？ #

多容器（集群、多实例）环境中，JVM进程相互独立，跨容器直接操作线程不可能，需调整架构逻辑：

• 任务与线程解耦：不再存储Thread对象，改为为每个耗时任务分配唯一ID，记录任务的状态（运行中/已终止）、所属容器实例标识等元数据。
• 实例级任务管理：每个容器实例维护自身的任务列表，对外提供查询、终止接口；同时定期将任务状态同步到公共存储。
• 定向终止触发：终止任务时，先通过公共存储定位任务所属的容器实例，再调用该实例的终止接口，由实例自行处理任务中断。
• 独立线程池执行任务：不要复用Web容器线程处理耗时任务，自行创建ThreadPoolExecutor线程池，安全管理任务的生命周期与中断逻辑。

3. 存储任务数据的公共存储方案建议 #

注意：绝对不能存储Thread对象，它是JVM内部对象无法序列化，跨实例传输或持久化都会失败，需存储任务元数据（任务ID、状态、实例标识等），推荐方案：

分布式缓存（如Redis） #

• 优势：读写性能极高，支持过期时间，适合存储临时运行中任务数据。可用Hash结构存储每个实例的任务列表，或用Set存储全局运行中任务ID，关联所属实例信息。
• 适用场景：任务生命周期短、无需持久化、对性能要求高的场景。

关系型数据库（如MySQL） #

• 优势：支持持久化，可完整记录任务全生命周期（创建、运行、终止、结果），适合需要审计、追溯任务历史的场景。表结构可包含任务ID、实例ID、状态、创建时间、终止时间等字段。
• 适用场景：需长期保存任务数据、有复杂查询需求的场景。

分布式消息队列（辅助方案） #

• 配合缓存或数据库使用，跨实例触发终止时，通过消息队列（如RabbitMQ、Kafka）向目标实例发送终止指令，实例监听消息并执行中断逻辑，同步更新公共存储中的任务状态。

内容的提问来源于stack exchange，提问作者Kiva Player