前段时间做批量文件解析脚本时，纠结了很久单线程和多线程哪个好，瞎折腾了两天才摸透两者的真实使用边界。

最开始写的是单线程代码，需求是批量读取本地几百个Excel文件，提取表格内的有效数据录入系统。代码写完跑测试的时候，速度慢的离谱，一百多个文件要跑完足足需要十几分钟，后台控制台一直是单调的加载状态，半点进度推进的迹象都没有。当时下意识就觉得，肯定是单线程效率太低，多线程一定能解决这个卡顿问题，于是立马着手改写代码。

换成多线程模式后，刚开始确实看到了明显变化，文件读取的速度快了一大截，页面刷新也变得频繁，一度以为问题彻底解决了。可没跑多久，bug就接连爆发，频繁出现数据错乱、文件重复读取、部分数据丢失的问题，甚至偶尔会直接触发系统文件占用报错，导致整个程序直接崩溃闪退。

单线程的实际使用短板与适配场景

折腾好久才搞明白，这次的坑根本不是线程模式选错这么简单。这批Excel文件存在相互关联，部分表格数据需要按固定顺序依次读取、校验、录入，单线程的逻辑是顺序执行，一步做完再走下一步，虽然速度慢，但绝对不会出现数据混乱、资源抢占的问题。之前的慢，只是单纯的串行执行耗时累积，在有序数据处理、本地磁盘读写这类对执行顺序有要求的场景里，单线程的稳定性是没法替代的。

单线程唯一的问题，就是极致低效。所有任务排队执行，哪怕其中一个任务只需要一秒，也要等前一个复杂任务跑完才能启动。遇到大批量独立、无关联的简单任务，这种执行模式的弊端会被无限放大，完全浪费设备的运行资源，这也是最开始测试时卡顿严重的核心原因。

多线程的实操隐患与适用范围

多线程的优势，是可以同时开启多个任务进程，并行处理批量任务，能最大化利用CPU资源，大幅压缩整体运行时长。但它的致命缺陷也很明显，多线程会抢占系统资源，多个进程同时读写同一文件夹、同一数据接口时，没有天然的秩序约束，很容易出现资源冲突。

这次出错就是因为忽略了数据关联性，盲目使用多线程。多个线程同时读取关联表格，有的线程还没读取完基础数据，后续线程就已经开始录入，直接造成数据错位、缺失。而且多线程开启过多时，会产生大量冗余进程，占用内存过高，低配设备很容易出现卡顿、程序闪退的情况，可控性远不如单线程。

线程模式核心优势主要短板适配场景
单线程逻辑简单、数据稳定、无资源冲突串行执行、整体效率偏低有序读写、关联数据处理、少量任务运行
多线程并行运行、资源利用率高、速度快易数据错乱、有资源抢占风险独立批量任务、无顺序要求、高并发需求

没有绝对更好的线程模式。

后面折中调整了方案，关联数据的核心录入环节保留单线程，保证数据准确无误，零散的独立文件预处理、格式清洗环节改用多线程，兼顾了速度和稳定性。改完之后，程序既没有崩溃报错，运行速度也提升了近三倍，完全适配当下的工作需求。

那天调试到深夜，保存完最终代码，关掉编辑器的那一刻，屏幕黑下来的倒影里，只看得见自己疲惫耷拉下来的眼皮。