Java并发编程实战：多线程与线程池在智能仿真系统中的应用

1. 项目背景与核心思路

这两年做过的并发项目里，真正让我觉得“有仿真味”的，是一个多智能体协同仿真的调度系统。项目标题写着“JAVA|智能仿真并发项目-进程与线程”，说白了就是要在单个应用里模拟出大量独立实体同时运行、互相协作、争夺资源的场景，底层靠的是JAVA并发体系里的进程与线程机制。这个方向在面试八股里被人聊烂了，一旦落到真实仿真项目，你会发现课本章节和工程实践之间隔着一道很深的沟。

我最早接手时的需求一句话能说完：要在城市交通仿真场景中模拟数万辆网约车同时接单、行驶、充电、上报状态，后台需要实时统计订单并发峰值、路口拥堵指数和充电桩占用率。数据量看着不算夸张，但难点在于每个仿真单元都有独立状态，彼此会影响决策，还要求整个系统在网络抖动、线程阻塞、资源争抢时保持数据一致性。

这里面最核心的矛盾不是“能不能跑”，而是“怎么在真正高并发下让仿真结果仍然可信”。仿真程序里的每个实体不是单纯的HTTP请求，而是有生命周期、有决策逻辑、有交互规则的Actor。你没法用传统同步接口按顺序轮询每一辆车，那样整体吞吐量会低到没法看；也没法无脑给每个对象开一个线程，千级以上的调度成本就会把系统拖垮。

所以这个项目最终走的是“有限线程池+任务分片+协作式调度”的路线：先理解进程与线程的边界在哪里，再决定什么任务该放进程里、什么任务该放线程里，最后借助JUC包下的工具做到可控并发。整个过程踩了太多坑，这篇文章就把我的设计思路、关键实现和真实调优过程整理出来，给做仿真、做调度、做高并发IM这类方向的同学一个可参考的样本。

需要先泼一盆冷水：进程与线程这个话题在Java里最容易被误解。很多人觉得“多线程就是快”，但仿真场景里恰恰相反——线程越多竞争越多，锁竞争和上下文切换会吃掉大量CPU时间片。我甚至见过一个团队为了“提高并发”硬开了400个线程，结果核心线程调到16核机器上，吞吐率反而不如64线程的时候。这个项目最大的收获，就是逼着我去思考每一个线程存在的理由。

2. 智能仿真项目中的并发模型设计

2.1 为什么仿真类项目必须认真拆分进程与线程

仿真项目跟普通Web后端的并发模型有很大区别。普通后端是“请求-响应”模型，一次请求的生命周期很短，线程池接住请求、查数据库、返回结果就完事了。但智能仿真里，每个仿真实体都是一个持续运行的有状态对象，它会根据环境变量不断调整自己的行为，甚至还会跟其他实体发生碰撞、协商、通信。

我第一次设计时照搬了Web项目的做法，用ExecutorService建了个默认线程池，把每辆车的仿真循环直接丢进去跑。结果跑起来之后发现，大量线程堆积在同一批CPU核心上抢时间片，状态流转的先后顺序开始乱套，仿真结果的波动性陡增——同一个随机种子跑出的结果在两次运行之间有明显差异。这不是算法错了，而是并发调度破坏了仿真的确定性。

进程与线程的架构边界，在仿真项目里必须严格区分开：

• 进程：负责承载不同仿真域的隔离环境。一个进程挂掉不能影响其他仿真域，比如路网环境进程挂了不能把交易订单进程一起带走。进程间通信走协议栈（Socket、共享内存、消息队列），适合低频、高可靠的数据交换。
• 线程：负责一个进程内部的高频任务调度和资源共享。线程间通信靠共享内存，速度快，但必须配合锁、原子类、并发容器来保证可见性和一致性。

后来我调整架构，采用“一域一进程，进程内分线程池”的模型。城市路网仿真、车辆决策引擎、订单撮合引擎分别拆成独立进程部署，进程内再按业务域划分线程池，互不干扰。这个改动之后，一个仿真域崩溃不再影响整体任务，排查问题也变得清晰很多。

2.2 线程池在仿真调度中的价值与前车之鉴

线程这个东西是有创建成本的，从系统调用到栈空间分配，再到线程上下文切换，每一步都要花钱。真实仿真项目里，任务体量经常是百万级甚至千万级的，如果任务一多就开线程，操作系统会被拖到崩溃边缘。我用一个实际数字说话：单台Linux服务器上创建线程的默认栈空间是1MB，1000个线程光是栈内存就吃掉1GB，这还没算线程调度器本身的消耗。所以线程池不是优化选项，而是必需品。

Java里ThreadPoolExecutor是最常用的线程池实现，我在这个项目里用它的七个参数做了精细控制：

• 核心线程数（corePoolSize）：决定了常驻工作线程数量，主要承接持续性的仿真任务。
• 最大线程数（maximumPoolSize）：决定了极端峰值下能扩到多少线程，是系统的安全阀。
• 空闲线程存活时间（keepAliveTime）：非核心线程空闲后多久被回收，避免峰谷波动时资源空转。
• 任务队列（workQueue）：缓冲来不及处理的任务，我用的都是有界队列，防止内存被冲垮。
• 线程工厂（threadFactory）：给线程起名、设置优先级，方便监控和排查。
• 拒绝策略（handler）：队列满载后怎么办，我选了CallerRunsPolicy，让提交任务的线程自己消化压力，而不是直接丢任务。

刚才说的坑就来自“无脑调大核心线程数”。我最早把Intel 16核机器上的核心线程数调到128，理论上线程越多任务消化越快，结果发现上下文切换占比奇高，CPU时间大量消耗在保存和恢复寄存器上，业务处理效率反而跌了三成。后来参考Amdahl定律重新算，核心线程数压到略大于CPU核心数，保留一部分扩展缓冲，整体吞吐立刻飙升。

2.3 任务拆分粒度对并发效果的决定性影响

仿真任务不是每个实体一个线程，那样会退化成线程地狱。我的做法是把仿真实体按区域、按行为链路分片，再把分片任务提交到线程池。比如路网仿真按“路口网格”切分，每个线程处理一片网格里的上百辆车，而不是一辆车一个线程。

任务拆分的粒度直接影响锁竞争和上下文切换频率。粒度过粗，一个线程要处理几百个实体的完整决策链，单线程计算耗时过长，并发优势发挥不出来；粒度过细，锁竞争频繁，线程调度开销占比陡然上升。这个项目里的经验值是：每个任务单轮运行时间控制在5到20毫秒之间，既能发挥多核并行，又不会因为频繁切换而白忙活。

把这个思路落到代码上，就是按任务类型定制Runnable接口的不同实现：车辆决策任务、路径规划任务、能源消耗计算任务各自独立，互不依赖的可以并行，有依赖关系的通过Future串联等待结果。通过这种方式，系统的并发度并非取决于实体数量，而是取决于可并行任务的分解程度。

3. 进程与线程实现的核心细节

3.1 进程间通信（IPC）在仿真架构中的落地

进程与进程之间不能直接共享变量，必须通过操作系统提供的IPC机制交换数据。我在这个项目里主要用到了三种方案：

第一，Socket + JSON协议，适合两个仿真域之间的低频事件通知。比如车辆决策进程检测到“严重拥堵事件”，通过TCP推送消息给路网控制进程。优点是天然跨机器，后续做分布式部署不用改代码；缺点是吞吐有上限，不适合高频状态同步。

第二，共享内存 + 信号量，适合跨进程需要高频读写的实时状态数据。我用MappedByteBuffer映射共享文件区域，配合同步信号量控制读写冲突。实测单机内跨进程状态同步的时延能压到微秒级，比Socket方案快了不止一个数量级。

第三，消息队列中间件，适合下游无法保证实时消费、需要削峰填谷的场景。仿真开始时把任务批量塞进队列，消费者按自己节奏从队列里取消息，天然做到生产消费的解耦。

用IPC需要格外小心的是数据序列化开销。如果两个进程需要交换高频实时数据，把Java对象转JSON再转回来的成本会非常惊人。建议对这类数据单独设计紧凑型二进制协议，字段的布尔值合并成一个字节位图，数值直接填原始类型，不要用包装类，能显著压缩序列化后的体积。

3.2 线程状态流转与上下文切换的仿真模拟

线程从创建到消亡会经历NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED这几个状态。在仿真场景里，线程状态流转本身就值得建模：不同状态的线程数量就是系统负载的一面镜子。

这个项目里我写了一个线程状态观测组件，利用ThreadMXBean定时抓取所有工作线程的状态，统计RUNNABLE占比、BLOCKED占比、WAITING占比。当观察到RUNNABLE占比长期高于90%时，说明CPU资源几乎被算满，需要限制新增并发；当BLOCKED占比超过15%时，说明锁竞争已经相当严重，需要优化锁粒度或者改用无锁数据结构；当WAITING占比高但吞吐低的时候，则意味着任务被阻塞在IO上，应该考虑异步化而不是继续加线程。

上下文切换的开销虽然看不见摸不着，但它是影响并发仿真系统性能的隐形杀手。现代操作系统的时间片通常在1到10毫秒之间，每切一次线程，CPU要执行一次模式切换、保存当前线程的执行上下文、加载新线程的执行上下文、刷新TLB缓存。这个成本大约是几微秒到十几微秒，看起来不贵，可一旦切换频率达到每秒几十万次，累计消耗就会非常可观。

我在模拟系统里专门加了一个指标：每完成一万个仿真任务消耗的CPU时间。这个指标能从宏观上反映上下文切换是否失控，比盲目盯线程数有意义得多。真实观测中，线程数超过CPU核心的2到3倍以后，这个指标会急剧恶化，这也是我最终确定线程池上限的依据。

3.3 并发安全与数据一致性的保证

仿真项目最怕的就是数据不一致：两辆车决策线程同时修改同一个路口的占用明细，导致车辆重叠；订单线程读到了支付线程还没写完的半截数据，导致金额错乱。这类问题在Web后端容易规避，因为请求边界清晰；但在有状态的长生命周期仿真里，共享数据模型俯拾皆是，线程安全是第一天就要考虑的事。

我在项目里建立了几条明确的设计规约：

第一条，能加final就不加锁。 仿真模型里很多参数是启动时确定后不再变化的，比如车辆最大速度、电池容量、地图拓扑。把这些字段声明成final并用不可变对象封装，多个线程并发读根本不需要加锁，最省心。

第二条，能用并发容器就不手写同步。 ConcurrentHashMap在Java 8之后做了大量优化，读路径完全无锁，写路径只会锁住被影响的桶。比给整个Map加一把大锁吞吐量高出几个数量级。CopyOnWriteArrayList适合读多写少的场景，比如仿真配置的热更新，直接复制一份再替换引用，读线程永远看到一致快照。

第三条，锁的粒度能小则小。 实在躲不开需要锁保护的共享资源，优先用“分段锁”思路。这正好对应ConcurrentHashMap的设计哲学——把一个大锁拆成多个小锁，只有落在同一段上的线程才需要竞争。我在路口状态管理器里按路口ID取模分段，把争抢压力从“全局一把锁”降级成“每16个路口一把锁”，效果立竿见影。

第四条，原子变量能替代锁的优先用原子变量。 对于计数器、序号生成器这类单一数值操作，AtomicLong的CAS机制比加锁轻得多。比如仿真全局时钟的推进、任务序号分发，直接用AtomicLong实现，无锁无阻塞，性能要比synchronized实现高出几倍。

3.4 死锁的识别与规避

多线程仿真项目里死锁是最让人头大的问题之一。两个线程各自握着一把锁，又都在等对方手里的锁，谁也不肯放手，系统就僵死在这里。在真实仿真系统里死锁的可怕之处在于它不报错、不崩溃，就是任务进度卡住不动，CPU利用率还会异常升高，等你发现的时候整个仿真已经停摆了很久。

我在这项目里遇到过一回经典死锁：车辆决策线程拿到了“路径锁”，又想去拿“充电桩锁”；与此同时充电桩管理线程拿到了“充电桩锁”，又想去拿“路径锁”，两边互相等待，整个仿真集群的线程池全部堵死。

解决这个问题的第一步是定位，我用了JStack手动抓线程快照，看到“Found one Java-level deadlock”这个关键提示后，立刻就能分辨出哪两把锁形成了环形等待。但手工排查终究太被动，后来我在代码层面做了三道防线：

• 按固定顺序加锁：所有需要同时拿多把锁的地方，都按系统内预先定义好的全局锁顺序获取，彻底消除循环等待。
• 用带超时的锁替换一把锁到底的写法：ReentrantLock的tryLock允许在指定时间内获取不到锁就放弃，避免无限期等待。
• 缩小锁范围：把原本覆盖整个方法的大锁拆成覆盖特定代码块的细锁，锁内只处理必须共享的部分，其他操作都在锁外完成。

做完这三步之后，死锁问题在这个项目里再没出现过。如果你在做类似的多线程系统，一定要在一开始就定好加锁秩序，别等到线上事故再来亡羊补牢。

4. 核心并发容器的选取与性能对照

4.1 仿真状态存储用什么数据结构

仿真系统的数据形态决定并发容器的选型。我从项目里拆出三个最典型的使用场景来做表格对照。

有一段时间我用Hashtable来存车辆状态，因为它是早期Java就提供的线程安全Map。结果压测的时候发现吞吐只有ConcurrentHashMap的十分之一左右，因为Hashtable在所有读写操作上都加了全局锁，任何并发都会冲突，根本发挥不了多核性能。后来我全部换掉，改用ConcurrentHashMap并做初始化容量预估，频繁扩容的问题也一并解决了。

4.2 阻塞队列在仿真调度中的妙用

仿真调度系统本质上是一个生产-消费模型：一批线程生产仿真任务（比如新进入路网的车辆、新产生的抢单请求），另一批线程消费这些任务做具体计算。中间必然需要一个队列做缓冲。

我选用的是LinkedBlockingQueue，默认构造函数不设上限，这是最危险的做法。无界队列在极端流量下会无限堆积内存，最终把JVM堆内存耗尽触发OOM。我上线前就把队列换成有界模式，容量按每秒最大任务生产量乘以峰值持续时间的经验公式估算。

队列的拒绝策略也得仔细斟酌。线程池默认的AbortPolicy直接抛异常，在仿真系统里很可能导致批量任务中断；DiscardPolicy又把任务悄悄丢了，仿真结果就会“缺人”。最终我选择了CallerRunsPolicy，队列满了就让提交任务的线程自己执行这个任务，把背压传导回上游，让系统整体降速而不是崩溃。

4.3 ForkJoinPool在分治型仿真任务中的应用

仿真里有一类典型的分治任务：计算某个区域的路网拥堵指数，需要先算出该区域内所有路段的流量，再汇总成区域指数，最后合并成全城指数。这种“分而治之”的结构用ForkJoinPool天然合适。

ForkJoinPool的核心思想是把大任务递归拆成小任务，工作线程忙完后还能通过“工作窃取”机制去偷别的线程队列里还没完成的任务。四个字概括就是“负载均衡”。Java里最经典的实现是ForkJoinTask的子类RecursiveTask。我实现了一个拥堵指数计算任务，把整个路网按网格逐层二分，最小网格内车辆数低于阈值就直接算，否则继续拆。这种方案不仅代码结构清晰，实际性能比单线程顺序计算快了将近6倍，基本上逼近了16核机器的并行上限。

有一点需要注意：ForkJoinPool的并行度默认取CPU核心数，不必调大。工作窃取虽然好，但任务拆得太细反而会导致窃取开销大于计算收益，我这边的经验是拆分阈值取到最小计算单元耗时在几十微秒的量级就算到头了。

5. 实操环节：搭建一个微型智能仿真并发框架

5.1 架构总览与核心类说明

说再多理论不如直接上手撸一个能跑的框架。下面这套微型智能仿真并发框架，是我从正式项目里抽出来的简化版本，核心逻辑不变，但只剩一个进程、三个线程池，适合新手完整跑通并理解进程与线程在Java里的配合方式。

框架的总体结构分三层：

• 第一层是仿真入口，负责加载配置、启动线程池、注入种子数据。
• 第二层是任务调度层，负责把仿真任务按区域分组并提交到任务线程池。
• 第三层是执行层，由具体工作线程处理车辆状态、路径计算、充电调度等仿真逻辑。

核心类包括：SimulationEngine（引擎入口）、TrafficGrid（路网网格，模拟共享数据）、VehicleTask（车辆仿真任务，实现Runnable）、ChargingStationManager（充电站管理，模拟资源竞争点）。

主线程池配置方面，我选择了计算密集型任务的标准配置：

java复制ThreadPoolExecutor taskPool = new ThreadPoolExecutor(
    8,                         // 核心线程数：接近CPU核心数
    16,                        // 最大线程数：峰值扩容缓冲
    30L, TimeUnit.SECONDS,     // 空闲线程回收时间
    new ArrayBlockingQueue<>(10000), // 有界任务队列
    new CustomThreadFactory("vehicle-task"),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

核心线程为什么设成8而不是直接等于16核？原因很简单：这台机器除了计算任务还要跑监控线程、日志线程和定时调度任务，全部塞满计算线程会导致其他基础任务的响应延迟。而且Amdahl定律告诉我们串行比例哪怕只有5%，并行上限也只有20倍左右，线程数量超过需求是纯浪费。

5.2 核心代码实现带注释解读

下面这段代码是整个框架的最核心部分，我加入了详细注释，建议直接跟着敲一遍，跑起来再去改参数看效果。

java复制public class VehicleTask implements Runnable {
    private final String vehicleId;
    private final TrafficGrid grid;
    private final ChargingStationManager stationManager;

    public VehicleTask(String vehicleId, TrafficGrid grid, ChargingStationManager stationManager) {
        this.vehicleId = vehicleId;
        this.grid = grid;
        this.stationManager = stationManager;
    }

    @Override
    public void run() {
        // 模拟车辆决策过程：读取当前网格状态
        int currentLoad = grid.getLoad(vehicleId);
        
        // 模拟不同车辆类型的行为差异
        if (currentLoad > 80) {
            // 拥堵区域，执行绕路决策
            reroute();
        } else {
            // 正常行驶，推进仿真时钟
            drive();
        }
        
        // 低电量车辆申请充电，这里会触发资源竞争
        if (needsCharge()) {
            stationManager.applyCharging(vehicleId);
        }
    }

    private void drive() {
        // 这里可以补充真实的路径计算逻辑
        // 实际项目里会是几十行的坐标计算和状态流转
    }

    private void reroute() {
        // 模拟绕行：网格重新计算通行代价
    }

    private boolean needsCharge() {
        // 用ThreadLocalRandom避免多个线程争抢同一个Random实例
        return ThreadLocalRandom.current().nextInt(100) > 85;
    }
}

这段代码初看简单，但处处是并发设计的细节。比如ThreadLocalRandom.current()每线程独立随机数生成器，就是为了避免多个线程共享一个Random实例时产生竞争；grid.getLoad()在真实实现里就是从一个ConcurrentHashMap上读值，无锁高性能。

为了构建仿真场景，用下面的引擎代码把几百辆车丢进线程池并发跑起来：

java复制public class SimulationEngine {
    private final ThreadPoolExecutor taskPool;
    private final TrafficGrid grid = new TrafficGrid();
    private final ChargingStationManager stationManager = new ChargingStationManager();

    public SimulationEngine() {
        this.taskPool = new ThreadPoolExecutor(
            8, 16, 30L, TimeUnit.SECONDS,
            new ArrayBlockingQueue<>(10000),
            new CustomThreadFactory("sim-task"),
            new ThreadPoolExecutor.CallerRunsPolicy()
        );
    }

    public void start(int vehicleCount) {
        // 按网格区域分组，模拟任务分片逻辑
        for (int i = 0; i < vehicleCount; i++) {
            String vehicleId = "CAR-" + i;
            taskPool.execute(new VehicleTask(vehicleId, grid, stationManager));
        }
    }

    public void shutdown() {
        taskPool.shutdown();  // 不再接受新任务
        try {
            // 等待已有任务执行完毕，最多等60秒
            if (!taskPool.awaitTermination(60, TimeUnit.SECONDS)) {
                taskPool.shutdownNow();  // 超时后强制中断
            }
        } catch (InterruptedException e) {
            taskPool.shutdownNow();
            Thread.currentThread().interrupt();
        }
    }
}

5.3 锁竞争场景的模拟与优化演示

这个框架里的ChargingStationManager是最容易产生锁竞争的地方。每辆车都要看充电桩是否空闲，如果空闲就占用，用完后释放。如果直接在方法上加synchronized，那么几百辆车同时申请充电时，只有一辆能拿到锁，其他车辆全部阻塞，整体吞吐会瞬间跌到谷底。

我的优化演示把一把全局锁拆成了“分段锁”，把充电桩按编号分到若干段中，每段独立加锁。

java复制public class ChargingStationManager {
    // 100个充电桩，分10段，每段10个
    private final Object[] locks = new Object[10];
    private final boolean[] stations = new boolean[100];

    public ChargingStationManager() {
        for (int i = 0; i < locks.length; i++) {
            locks[i] = new Object();
        }
    }

    public boolean applyCharging(String vehicleId, int stationIndex) {
        int segment = stationIndex / 10;
        synchronized (locks[segment]) {
            if (!stations[stationIndex]) {
                stations[stationIndex] = true;  // 占用充电桩
                return true;
            }
        }
        return false;
    }

    public void releaseCharging(int stationIndex) {
        int segment = stationIndex / 10;
        synchronized (locks[segment]) {
            stations[stationIndex] = false;
        }
    }
}

这段代码把一把全局锁变成了10把小锁，两个车辆请求不同段的充电桩时完全不会互相阻塞。我在压测里实测过，优化前后同样条件下，峰值吞吐从每秒处理1.2万次申请提升到每秒4.6万次，效果非常直观。

5.4 用JMeter模拟外部并发请求验证系统承压

仿真任务内部的并发跑通了，外部还有一层考验：仿真系统要向外部提供实时状态查询接口，调度员大屏、用户App都会高频拉取仿真进度。这层接口的并发能力，我用JMeter做了压测验证。

JMeter压测里最容易被忽略的是“并发十个参数不同的post请求”这种真实场景。很多人偷懒用CSV只准备一组数据，实际跑起来看到的监控曲线完全不具有参考性。我这里用的是JMeter的CSV Data Set Config组件，准备了一万条不同车辆ID的查询参数，保证每个请求都携带不同参数，模拟真实用户各不相同的行为。

压测参数实际结果如下：

注意200并发到400并发出现了拐点，吞吐量反而下降、错误率上升。原因不是服务器扛不住400活跃请求，而是线程池被打满后，队列堆积、调用者线程被反压拖慢，整体响应链条拉长。这个数据点提醒我：系统的最优工作点不是最大并发数，而是吞吐率不再增长的那个拐点，生产环境要把容量冗余留在这个拐点之下。

6. 常见问题与排查技巧实录

6.1 压测时CPU跑不满但吞吐上不去

这是最诡异的现象：CPU利用率只有40%，但应用吞吐已经上不去了。很多人第一反应是加机器，但问题往往出在线程被阻塞IO卡住。仿真系统里最常见的坑就是在仿真循环里嵌了同步网络请求，比如车辆状态变化后立即同步上报到外部存储，导致工作线程大部分时间在等待网络IO响应而不是在做计算。

排查方法很简单：抓线程快照，看有多少线程状态是WAITING或者BLOCKED。如果大量线程卡在Socket读写上，就说明同步IO拖死了并发度。解决办法是把同步上报改成异步提交。用一个独立的单线程调度器循环批量上报状态，或者直接扔进消息队列，让工作线程从IO等待中解脱出来。

6.2 任务队列疯狂堆积，但线程数却上不去

ThreadPoolExecutor的执行机制有一个关键细节，很多人会忽略：只有工作队列满了之后，才会创建非核心线程去处理新任务。如果你用的是无界队列，那么非核心线程可能永远都不会被创建，大量任务全部堆积在队列里慢慢排队，系统的响应延迟会无限拉长。

解决办法有两个方向。要么改用有界队列，让队列装满后触发扩容线程的机制；要么用SynchronousQueue这种不缓存任务的队列，任务提交后必须马上有线程接手，倒逼线程池创建新线程。两种方案我都实测过，最后选了有界队列配合合适容量，既能平滑流量波动，又不会让堆积失控。

6.3 线程池里的线程名字全是“pool-1-thread-1”，排查靠猜

生产环境里排查问题，线程名叫什么直接影响效率。默认线程工厂创建的线程名完全没有业务含义，线上拿到一堆pool-1-thread-1根本不知道是哪个模块的线程。这个项目里我第一天就写了自定义线程工厂，把“vehicle-task-1”“charging-manager-2”这样的业务名直接编码进线程名。

java复制public class CustomThreadFactory implements ThreadFactory {
    private final String prefix;
    private final AtomicInteger counter = new AtomicInteger(0);

    public CustomThreadFactory(String prefix) {
        this.prefix = prefix;
    }

    @Override
    public Thread newThread(Runnable r) {
        Thread thread = new Thread(r);
        thread.setName(prefix + "-" + counter.incrementAndGet());
        thread.setDaemon(false);  // 主线程退出时，仿真线程不允许被直接结束
        thread.setUncaughtExceptionHandler((t, e) -> {
            System.err.println("线程 " + t.getName() + " 发生未捕获异常: " + e);
        });
        return thread;
    }
}

这个工厂同时设置了未捕获异常处理器，线程池里跑的任务如果抛出了未检查异常，线程池表面上是不会把异常吐出来的——它会静默吞掉，甚至还会创建一个新线程继续跑。没有这个处理器，很多仿真任务的异常会完全不可见，最后只能靠“结果不对”倒推排查。

6.4 ThreadLocal在仿真线程池里的内存泄漏

ThreadLocal在线程池场景下是一个经典的陷阱。线程池的特点是线程复用，线程不会随任务结束而销毁，因此ThreadLocal中存储的变量会在整个线程生命周期内一直存在，不会被GC回收。

比如我在车辆状态追踪里用过ThreadLocal缓存“当前车辆上下文”，结果任务跑完后没清理，下一个任务复用同一线程时读到了上一个车辆残留的上下文，整个仿真结果全部错乱。

正确用法是任务结束时在finally块里调用remove：

java复制try {
    // 业务逻辑
} finally {
    contextThreadLocal.remove();  // 防止线程复用导致数据串线
}

ThreadLocal不是不能用，而是必须明白它的生命周期跟线程绑定，而不是跟任务绑定。在线程复用的场景里，一旦忘记清理，轻则数据飘移，重则因为持有大对象导致内存泄漏。这个教训我是真金白银换来的。

6.5 常见问题速查表

7. 性能调优：从一个真实瓶颈说起

这个项目上线前做过一轮完整的性能压测，暴露出来的最大瓶颈不在计算逻辑，而在日志输出。每一辆车的状态变化都会打一条INFO日志，每秒产生的日志量高达几十万行，Logback同步写入磁盘把工作线程卡得死死的。我当时看到线程Dump里大量线程处于文件IO阻塞状态才意识到问题。

解决方案分三步走：

第一步，把日志级别从INFO降到WARN，仿真过程中的高频追踪日志全部关掉，只保留关键节点的状态快照。这个改动直接砍掉了九成日志IO压力。

第二步，核心业务日志改成异步输出，用Logback的AsyncAppender搭配独立IO线程，业务线程只往内存队列里丢日志对象，由专属线程负责写盘。这个改动让工作线程彻底从磁盘IO中解放出来。

第三步，把“每车每条日志”改成“每车聚合日志”。车辆在一个仿真周期内的多次状态变化汇总成一条结构化日志，写入时一次性输出。日志量瞬间降了一个数量级，而且后续做数据分析时还更方便。

这三个步骤做完后，同样的硬件环境下系统吞吐提升了一倍多。这件事给我最大的启发是：性能调优不要一头扎进并发参数里去抠，先看线程的时间都去哪儿了。数据在IO上排队，线程池调的再精细也是给堵住的下水道加泵。

另一个值得一提的调优是GC压力。仿真系统每秒创建大量短生命周期对象，比如坐标点、状态快照、临时决策对象，老年代容易被快速撑满触发Full GC。我用了JFR监测GC频率，发现每秒钟有40多次Minor GC和每秒一次的Major GC，Major GC的停顿时间甚至达到几百毫秒。后来用JVM参数把新生代调大、开启对象分配指针压缩，同时优化代码减少临时对象创建，总GC时间压缩了80%以上。在高并发仿真里，GC停顿就是最高贵的并发资源，必须斤斤计较。

8. 从单机并发到分布式仿真的一点延伸

这个项目的单机版本跑通了，后续需求自然延伸到更大规模：路网从一座城市扩展到三座城市，车辆规模从十万级升到百万级。单机内存和CPU都达到瓶颈，再靠线程池优化已经没有明显收益了，这时候必须考虑分布式。

分布式仿真的核心问题跟单机并发惊人地相似：单机里是“线程间共享内存”，分布式里是“进程间通过消息传递”。你完全可以把一台机器抽象成一个团队，把机器里的线程抽象成团队里的成员，团队之间靠消息通信而不是直接伸手拿别人的文件。

在架构演进上，我最先做的是把无状态任务和跨域状态变量分离。无状态任务（比如车辆路径计算、能耗估算）可以直接分发到任意机器，执行完把结果写回状态中心；跨域状态变量（比如全局拥堵指数、充电桩占用表）则收敛到一个独立的Redis集群热点存储，保证任何机器读到的都是同一份数据。

分布式并不改变并发设计的基本原则，只是把锁变成分布式锁、把线程池变成机器池、把内存状态变成外部状态存储。你在单机阶段养成的思维模型——拆分任务、控制并发度、关注资源竞争——在分布式里依然适用。

这里要提醒一句：不要轻易从单机跳到分布式。分布式会引入网络分区、消息丢失、时钟不一致等一堆新的麻烦。如果你的单机方案能扛住当前规模的十倍流量，先别急着拆分系统，把单机的线程模型打磨好、把状态存储选对，往往比盲目上集群划算得多。我见过太多项目就是在单机优化还没到位的情况下匆忙分布式化，最后两头吃亏。

9. 项目落地后的真实感悟

这个项目从设计到落地，前前后后花了一个多月。回头看，最大的结论是：并发不是玄学，它是一套关于资源分配的系统工程。Java里每个工具都是为特定场景设计的，选错工具然后靠“加大线程数”来补救，是注定要失败的。

几个特别想分享给后来者的经验：

第一，先摸清任务类型再定并发模型。计算密集型和IO密集型是两种完全不同的物种，前者拼CPU核数，后者拼等待策略。仿真项目里两类任务往往同时存在，务必要拆到不同的线程池里管控，混在一起就是互相拖累。

第二，监控是并发系统的第三只眼睛。没有线程Dump能力、没有GC日志、没有压测报告，你就是在闭着眼睛玩高并发。至少要有一套能从线程状态、队列深度、GC频率、CPU上下文切换四个维度观察系统的工具链。

第三，调优之前先消除浪费。我在这个项目里最有价值的调优动作是砍日志、减临时对象、去同步IO，这几件每件事的收益都超过调整线程池参数。先把时间浪费堵住，再谈并发配置优化，是性价比最高的路径。

第四，仿真项目要保证可重复性。为了让并发调度不影响仿真结果，我在关键决策点上引入了确定性调度策略——把部分随机数改用种子可控的方案，重要状态推进依赖事件序列号而非执行顺序。这样同一组输入参数下，并发程度不同但最终统计指标仍然收敛。这一点在真实仿真业务里非常重要，否则测试那边会因为“这次结果跟上次不一样”跟你纠缠到底。

如果你正在做类似的高并发仿真项目，或者只是在准备Java并发方向的面试，希望这篇实战笔记能给你带来一点参考价值。我自己最想表达的其实只有一句：多线程练到深处，你会发现真正的瓶颈从来不是语法和API，而是你对系统资源运转规律的敬畏心。