1. 为什么单线程压缩文件迟早会把你逼疯

做过文件处理的朋友应该都有这种体验：一个目录里躺着几千个日志文件、图片素材或者数据导出文件，产品经理轻飘飘一句“打个包给用户下载”，你就得老老实实写个循环，一个文件一个文件地读、压缩、写盘。单线程跑下来，小文件还好，一旦碰上几十上百兆的大文件，或者文件数量上了四位数，CPU占用上不去、磁盘IO倒是挺忙，进度条跟蜗牛爬一样，用户那边早就开始刷新页面骂娘了。

这个项目要解决的就是这个痛点：用Java线程池配合CountDownLatch，把原本串行的压缩任务拆成并行执行，同时保证主线程能准确知道“所有文件都压完了”再去做后续动作。说白了就是两件事——提速和同步。提速靠线程池，同步靠CountDownLatch。

适合谁来参考？我的判断是：写过Java基础语法、知道Thread和Runnable是怎么回事，但对线程池参数怎么调、CountDownLatch到底卡在哪个位置还比较模糊的同学。如果你已经能熟练手写ThreadPoolExecutor，那这篇你可以快速扫一眼，重点看后面关于阻塞队列选型和异常处理的坑。

关键词先摆出来：Java多线程、线程池、CountDownLatch、文件压缩、并发控制、ZipOutputStream、阻塞队列、线程安全。这几个词贯穿全文，后面每个章节都会围绕它们展开。

我先把结论亮出来：压缩这个场景天然适合并行化，因为每个文件的压缩过程是独立的，文件之间没有数据依赖。你压A文件的时候不需要等B文件的结果，这就是并行化的理论基础。但并行化之后会带来三个新问题：线程怎么管理、任务怎么分配、完成状态怎么同步。线程池解决前两个，CountDownLatch解决第三个。

注意：并行压缩并不是线程越多越快。磁盘IO是有上限的，线程数超过一定阈值之后，性能不升反降，后面我会给出具体的测算方法。

2. 整体方案设计与技术选型拆解

2.1 为什么是线程池而不是裸Thread

很多教程一上来就new Thread()，跑几个任务看起来也没问题。但压缩文件这个场景不一样，文件数量可能从几十到几万不等。你要是每个文件都new Thread()，线程创建和销毁的开销会直接把性能吃光，更严重的是，线程数量不受控，几千个线程同时抢CPU和IO资源，系统负载瞬间飙高，轻则响应变慢，重则直接OOM。

线程池的核心价值在于复用和限流。复用是指线程执行完一个任务后不销毁，回到池子里等下一个任务；限流是指池子里的线程数量有上限，不会无限膨胀。对于压缩场景，这两点都极其关键。

我选的是ThreadPoolExecutor而不是Executors工具类提供的快捷方法。原因很直接：Executors.newFixedThreadPool()底层用的是无界队列LinkedBlockingQueue，任务堆积过多时会一直往队列里塞，直到内存撑爆。生产环境里这种隐藏的OOM风险是不能接受的。自己new一个ThreadPoolExecutor，队列容量、拒绝策略、线程命名都能自己控制，出了问题也好排查。

2.2 CountDownLatch在这里扮演什么角色

CountDownLatch是一个同步辅助类，你可以把它理解成一个倒计时的门闩。初始化的时候给它一个计数，比如100，每完成一个任务就调用一次countDown()把计数减1，主线程调用await()卡在门口等，直到计数归零，门闩打开，主线程才继续往下走。

在压缩场景里，它的作用是这样的：主线程把N个文件的压缩任务提交给线程池之后，不能直接往下走，因为后面的动作（比如把最终的zip文件返回给用户、或者删除临时文件）必须等所有文件都压完才能做。这时候主线程就await()在那里等着，每个压缩任务完成时countDown()一下，全部完成后主线程被唤醒，继续执行收尾逻辑。

有同学会问：那我用Future.get()一个个等不行吗？行，但有几个问题。第一，Future.get()是有序等待，你得按提交顺序一个个get，如果第一个任务特别慢，后面即使完成了你也拿不到结果。第二，代码写起来啰嗦，要维护一个Future列表。CountDownLatch更轻量，语义也更清晰——我就是等所有任务完成，不关心单个任务的返回值。

2.3 压缩格式与流的选型考量

Java标准库自带java.util.zip包，核心类是ZipOutputStream。这个类本身不是线程安全的，多个线程同时往一个ZipOutputStream里写数据会导致数据错乱甚至抛异常。所以并行压缩有两种策略：

第一种是每个线程独立压缩一个临时zip文件，最后主线程把所有临时zip合并成一个。这种方案实现简单，但合并过程本身是串行的，而且临时文件占磁盘空间。

第二种是每个线程压缩完自己的文件后，把字节数组交给主线程，由主线程串行写入最终的ZipOutputStream。这种方案避免了临时文件，但主线程写入这一步是瓶颈。

我实际测试下来，对于文件数量多但单个文件不大的场景，第二种方案更优，因为压缩计算本身是并行的，只有最后的写盘是串行的，而写盘速度通常远快于压缩计算。对于单个文件特别大的场景，第一种方案反而更好，因为大文件的压缩计算时间长，合并的开销相对可以忽略。

提示：ZipOutputStream的putNextEntry()和closeEntry()必须成对出现，且不能在多线程环境下并发调用。这是最容易踩的坑之一。

3. 核心细节解析与实操要点

3.1 线程池参数怎么定才不翻车

ThreadPoolExecutor的构造函数有七个参数，我一个个说我的取值逻辑。

corePoolSize：核心线程数。压缩任务是CPU密集型和IO密集型混合的，因为压缩算法本身消耗CPU，读写文件消耗IO。经验值是把核心线程数设为CPU核心数 + 1。比如你的机器是8核，那就设9。为什么加1？因为IO等待的时候CPU是空闲的，多一个线程可以填补这个空隙。

maximumPoolSize：最大线程数。我一般设为核心线程数的2倍，也就是18。但这不是死规矩，如果你的文件普遍很大、压缩时间很长，可以适当调大；如果文件都很小，调大反而增加上下文切换开销。

keepAliveTime：非核心线程的空闲存活时间。设60秒就够了，压缩任务通常是一批一批来的，批次之间线程空闲一会儿很正常，没必要频繁销毁重建。

workQueue：阻塞队列。这是最关键的一个参数。我选的是ArrayBlockingQueue，容量设为文件数量。为什么不选LinkedBlockingQueue？因为ArrayBlockingQueue是有界的，任务提交过多时会触发拒绝策略，而不是无声无息地堆积到OOM。容量设为文件数量，保证所有任务都能进队列，不会触发拒绝。

threadFactory：线程工厂。一定要自定义，给线程起个有意义的名字，比如compress-pool-1、compress-pool-2。出问题的时候用jstack一看就知道是哪个池子的线程，排查效率翻倍。

handler：拒绝策略。我选的是CallerRunsPolicy，也就是当队列满了、线程也满了的时候，由提交任务的线程自己执行这个任务。这样做的目的是降级而不是丢弃，保证每个文件都能被压缩，只是速度慢一点。

int cpuCores = Runtime.getRuntime().availableProcessors(); int coreSize = cpuCores + 1; int maxSize = coreSize * 2; ThreadPoolExecutor executor = new ThreadPoolExecutor( coreSize, maxSize, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue<>(fileList.size()), new CustomThreadFactory("compress-pool"), new ThreadPoolExecutor.CallerRunsPolicy() );

3.2 CountDownLatch的初始化时机与计数逻辑

CountDownLatch的计数必须在提交任务之前初始化，计数值等于文件数量。这里有一个容易出错的细节：如果某个任务执行失败抛了异常，countDown()还会不会被调用？如果不做处理，异常会导致countDown()被跳过，主线程永远等不到计数归零，直接死锁。

我的做法是把countDown()放在finally块里，保证无论任务成功还是失败，计数都会减1。同时用一个AtomicInteger或者ConcurrentLinkedQueue记录失败的文件，主线程被唤醒后检查有没有失败任务，有的话做补偿处理。

CountDownLatch latch = new CountDownLatch(fileList.size()); ConcurrentLinkedQueue<String> failedFiles = new ConcurrentLinkedQueue<>(); for (File file : fileList) { executor.submit(() -> { try { compressFile(file); } catch (Exception e) { failedFiles.add(file.getName()); } finally { latch.countDown(); } }); } latch.await(); executor.shutdown();

注意：latch.await()最好带超时时间，比如latch.await(30, TimeUnit.MINUTES)。万一某个任务卡死，主线程不会无限等待，超时后可以主动干预。

3.3 文件分片策略与任务粒度控制

任务粒度太细，线程池调度开销大；粒度太粗，并行度不够。我的经验是：单个任务处理一个文件是最合适的粒度。因为文件压缩本身就是一个完整的、独立的工作单元，不需要再拆分。

但如果文件数量特别多，比如几万个，每个文件又特别小，那可以考虑把多个小文件合并成一个任务，比如每100个小文件打成一个包，作为一个任务提交。这样减少任务数量，降低调度开销。

判断标准很简单：如果单个文件的压缩时间小于1毫秒，那就合并；如果大于10毫秒，那就单独一个任务。1到10毫秒之间的，看文件总数，总数超过5000就合并，否则单独处理。

3.4 内存缓冲区的设置技巧

压缩过程中会频繁读写字节，如果每次读写都直接操作磁盘，IO开销会非常大。我的做法是在每个线程内部使用BufferedInputStream和BufferedOutputStream，缓冲区大小设为8KB到32KB之间。

为什么是8KB？这是大多数操作系统的页大小，也是磁盘块大小的常见值。设太小了频繁系统调用，设太大了浪费内存。32KB是我测试下来在大多数场景下性能最好的值，再大提升就不明显了。

还有一个细节：ZipOutputStream本身也有一个内部缓冲区，默认是512字节，可以通过构造函数指定更大的值。我一般设为8192，减少flush次数。

try (FileOutputStream fos = new FileOutputStream(zipFile); BufferedOutputStream bos = new BufferedOutputStream(fos, 32768); ZipOutputStream zos = new ZipOutputStream(bos)) { zos.setLevel(Deflater.BEST_SPEED); // ... }

Deflater.BEST_SPEED和Deflater.BEST_COMPRESSION的选择也要看场景。如果用户对下载速度敏感，选BEST_SPEED；如果对文件大小敏感，选BEST_COMPRESSION。我一般选BEST_SPEED，因为压缩率从60%提升到65%用户感知不明显，但压缩时间可能翻倍。

4. 完整实操流程与核心环节实现

4.1 环境准备与依赖说明

这个项目不需要任何第三方依赖，JDK自带的java.util.zip、java.util.concurrent、java.io就足够了。我用的是JDK 8，但代码在JDK 11和17上也能跑。如果你用的是JDK 17以上，ZipOutputStream的API没有变化，可以放心使用。

项目结构很简单，一个FileCompressor类作为主入口，一个CompressTask类实现Runnable接口，一个CustomThreadFactory类自定义线程工厂。不需要Spring、不需要Maven多模块，一个普通的Java项目就能跑。

4.2 核心压缩逻辑的编写

先写单个文件的压缩方法。这个方法接收一个文件和一个ZipOutputStream，把文件内容写入zip流。注意ZipOutputStream不是线程安全的，所以这个方法必须在单线程环境下调用。

private void compressFile(File file, ZipOutputStream zos) throws IOException { try (FileInputStream fis = new FileInputStream(file); BufferedInputStream bis = new BufferedInputStream(fis, 32768)) { ZipEntry entry = new ZipEntry(file.getName()); zos.putNextEntry(entry); byte[] buffer = new byte[8192]; int len; while ((len = bis.read(buffer)) != -1) { zos.write(buffer, 0, len); } zos.closeEntry(); } }

这段代码看起来简单，但有几个细节值得说。第一，ZipEntry的名字用file.getName()，如果不同目录下有同名文件，会冲突。解决办法是用相对路径作为entry名字，比如dir1/file.txt和dir2/file.txt。第二，closeEntry()必须在putNextEntry()之后调用，否则zip文件结构会损坏。第三，BufferedInputStream的缓冲区大小设为32768，和前面说的一致。

4.3 并行压缩的完整实现

现在把单文件压缩和线程池、CountDownLatch结合起来。我的实现方案是：每个线程独立压缩一个文件到临时zip文件，主线程等所有线程完成后，把所有临时zip合并成一个最终的zip文件。

为什么选这个方案而不是共享一个ZipOutputStream？因为共享ZipOutputStream需要加锁，加锁之后并行度就没了，等于白用线程池。独立压缩虽然多了合并步骤，但合并只是字节拷贝，速度很快。

public void compressParallel(List<File> files, File outputZip) throws Exception { int cpuCores = Runtime.getRuntime().availableProcessors(); int coreSize = cpuCores + 1; int maxSize = coreSize * 2; ThreadPoolExecutor executor = new ThreadPoolExecutor( coreSize, maxSize, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue<>(files.size()), new CustomThreadFactory("compress-pool"), new ThreadPoolExecutor.CallerRunsPolicy() ); CountDownLatch latch = new CountDownLatch(files.size()); ConcurrentLinkedQueue<File> tempZips = new ConcurrentLinkedQueue<>(); ConcurrentLinkedQueue<String> failedFiles = new ConcurrentLinkedQueue<>(); for (File file : files) { executor.submit(() -> { File tempZip = null; try { tempZip = File.createTempFile("compress-", ".zip"); try (ZipOutputStream zos = new ZipOutputStream( new BufferedOutputStream(new FileOutputStream(tempZip), 32768))) { zos.setLevel(Deflater.BEST_SPEED); compressFile(file, zos); } tempZips.add(tempZip); } catch (Exception e) { failedFiles.add(file.getName()); if (tempZip != null) { tempZip.delete(); } } finally { latch.countDown(); } }); } boolean completed = latch.await(30, TimeUnit.MINUTES); executor.shutdown(); if (!completed) { throw new RuntimeException("压缩超时，部分任务未完成"); } if (!failedFiles.isEmpty()) { throw new RuntimeException("以下文件压缩失败: " + failedFiles); } mergeZips(tempZips, outputZip); for (File tempZip : tempZips) { tempZip.delete(); } }

4.4 临时zip合并的实现

合并的逻辑就是遍历所有临时zip文件，把里面的entry逐个拷贝到最终的zip文件里。注意entry的名字要保留，否则解压后文件结构就乱了。

private void mergeZips(Queue<File> tempZips, File outputZip) throws IOException { try (ZipOutputStream finalZos = new ZipOutputStream( new BufferedOutputStream(new FileOutputStream(outputZip), 32768))) { finalZos.setLevel(Deflater.BEST_SPEED); byte[] buffer = new byte[8192]; for (File tempZip : tempZips) { try (ZipInputStream zis = new ZipInputStream( new BufferedInputStream(new FileInputStream(tempZip), 32768))) { ZipEntry entry; while ((entry = zis.getNextEntry()) != null) { finalZos.putNextEntry(new ZipEntry(entry.getName())); int len; while ((len = zis.read(buffer)) != -1) { finalZos.write(buffer, 0, len); } finalZos.closeEntry(); zis.closeEntry(); } } } } }

合并过程是串行的，但速度很快，因为只是字节拷贝，不涉及压缩计算。我实测下来，合并100个临时zip文件（总共约500MB）大概需要3到5秒，相比压缩本身的几十秒，完全可以接受。

4.5 线程工厂的自定义实现

线程工厂的作用是给线程起名字、设置优先级、设置是否为守护线程。压缩任务不应该设为守护线程，因为主线程需要等它们完成。优先级设为默认的NORM_PRIORITY就行，调高了反而可能影响其他业务线程。

static class CustomThreadFactory implements ThreadFactory { private final String prefix; private final AtomicInteger counter = new AtomicInteger(1); CustomThreadFactory(String prefix) { this.prefix = prefix; } @Override public Thread newThread(Runnable r) { Thread t = new Thread(r, prefix + "-" + counter.getAndIncrement()); t.setDaemon(false); t.setPriority(Thread.NORM_PRIORITY); return t; } }

4.6 参数测算与性能对比

我拿一个实际场景做了测试：1000个文件，每个文件平均500KB，总大小约500MB。机器配置是8核16G。

从数据可以看出，线程数设为CPU核心数时性能最好，超过核心数之后，上下文切换和IO争抢导致性能下降。这也验证了前面说的“不是线程越多越快”。

提示：这个测试结果和文件大小、磁盘类型（SSD还是HDD）强相关。SSD的IO并发能力强，可以适当增加线程数；HDD的磁头是物理瓶颈，线程多了反而导致磁头频繁寻道，性能急剧下降。

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

5.1 压缩后的zip文件打不开或损坏

这是最常见的问题，原因通常有三个。第一，putNextEntry()和closeEntry()没有成对出现，中间抛了异常导致closeEntry()被跳过。解决办法是用try-finally包住，确保closeEntry()一定被调用。第二，多个线程同时写同一个ZipOutputStream，导致数据交错。解决办法是每个线程独立写自己的临时zip。第三，ZipOutputStream没有正确关闭，缓冲区数据没有flush到磁盘。解决办法是用try-with-resources，保证流被关闭。

排查方法：用unzip -t命令测试zip文件完整性，或者用ZipFile类尝试打开，看抛什么异常。

5.2 主线程一直卡在await()不返回

这说明CountDownLatch的计数没有归零。原因通常是某个任务抛了异常，countDown()没有被执行。解决办法是把countDown()放在finally块里。还有一种可能是任务被拒绝了，CallerRunsPolicy虽然会由提交线程执行，但如果提交线程本身也在等待，就可能死锁。解决办法是确保提交任务的线程不是等待latch的线程。

排查方法：用jstack打印线程堆栈，看主线程卡在哪里，看线程池里的线程在做什么。如果线程池里的线程都在等待某个锁，那就是锁竞争问题；如果线程池是空的但latch没归零，那就是countDown()漏调了。

5.3 内存溢出OOM

压缩大文件时，如果一次性把文件内容读进内存，很容易OOM。解决办法是用流式读写，每次只读8KB，处理完就丢弃。另外，ZipOutputStream的内部缓冲区也会占用内存，如果压缩的文件特别多，可以考虑分批处理，每批处理完就释放资源。

还有一个隐藏的OOM点：ArrayBlockingQueue的容量设为文件数量，如果文件数量是10万，队列本身就会占用不少内存。解决办法是分批提交任务，比如每1000个文件一批，处理完一批再提交下一批。

5.4 压缩速度没有明显提升

如果用了线程池但速度没提升，先检查是不是IO瓶颈。用iostat或者系统自带的性能监视器看磁盘利用率，如果磁盘已经100%了，那加线程也没用。再检查是不是锁竞争，用jstack看线程状态，如果大量线程处于BLOCKED状态，说明有锁竞争。最后检查线程数是否合理，按前面的测算方法调整。

还有一个容易被忽略的点：压缩级别。如果设的是BEST_COMPRESSION，CPU是瓶颈，加线程有效；如果设的是BEST_SPEED，IO是瓶颈，加线程效果有限。

5.5 常见问题速查表

5.6 独家避坑经验

第一个坑：临时文件目录的选择。File.createTempFile()默认用的是系统临时目录，如果系统临时目录空间不足，会直接抛异常。我的做法是指定一个专门的临时目录，并且定期清理。

第二个坑：文件名的编码问题。ZipEntry的名字默认用UTF-8编码，但如果文件名包含中文，在某些解压工具上会显示乱码。解决办法是在创建ZipOutputStream之前设置ZipOutputStream.setEncoding("UTF-8")，或者用new ZipEntry(new String(name.getBytes("UTF-8"), "ISO-8859-1"))做转换。

第三个坑：线程池的关闭时机。executor.shutdown()只是不再接受新任务，已经提交的任务还会继续执行。如果要立即停止，用shutdownNow()，但会中断正在执行的任务，可能导致临时文件残留。我的做法是先用shutdown()，然后awaitTermination()等待一段时间，超时了再shutdownNow()。

第四个坑：CountDownLatch的计数不能重置。CountDownLatch是一次性的，计数归零后就不能再用了。如果需要重复使用，得用CyclicBarrier或者重新new一个。在压缩场景里，每次压缩任务都是独立的，重新new一个就行。

第五个坑：磁盘空间检查。压缩后的文件可能比原文件还大（如果原文件已经是压缩格式），提交任务前最好检查一下磁盘剩余空间，避免压到一半磁盘满了。

6. 进阶优化与扩展思路

6.1 用CompletableFuture替代CountDownLatch

CountDownLatch的语义是“等所有任务完成”，但如果你需要更复杂的编排，比如“所有任务完成后执行A，任意一个任务失败执行B”，那CompletableFuture更合适。CompletableFuture.allOf()可以等所有任务完成，anyOf()可以等任意一个完成，链式调用也比CountDownLatch更灵活。

不过CompletableFuture的异常处理比较绕，需要handle()或者exceptionally()，代码量比CountDownLatch多。我的建议是：简单的“等所有完成”用CountDownLatch，复杂的编排用CompletableFuture。

6.2 分批处理避免内存压力

如果文件数量特别大，比如10万个，一次性提交所有任务会导致队列占用大量内存。解决办法是分批提交，比如每1000个文件一批，每批处理完再提交下一批。这样内存占用可控，而且可以实时反馈进度。

int batchSize = 1000; for (int i = 0; i < files.size(); i += batchSize) { List<File> batch = files.subList(i, Math.min(i + batchSize, files.size())); CountDownLatch batchLatch = new CountDownLatch(batch.size()); for (File file : batch) { executor.submit(() -> { try { // 压缩逻辑 } finally { batchLatch.countDown(); } }); } batchLatch.await(); // 可以在这里更新进度 }

6.3 进度监控的实现

用户最关心的是“压到哪了”。用AtomicInteger记录已完成的任务数，主线程定期打印进度。注意不要在每次countDown()时都打印，那样日志会刷屏。我的做法是每完成10%打印一次。

AtomicInteger completed = new AtomicInteger(0); int total = files.size(); // 在任务里 int done = completed.incrementAndGet(); if (done % (total / 10) == 0) { System.out.println("进度: " + (done * 100 / total) + "%"); }

6.4 压缩格式的扩展

java.util.zip只支持zip格式。如果需要tar.gz或者7z，得引入第三方库，比如Apache Commons Compress。Commons Compress的TarArchiveOutputStream和GzipCompressorOutputStream也支持流式写入，可以套用同样的并行框架。

不过要注意，tar.gz的压缩比zip更高，但压缩速度更慢，线程数的设置需要重新测算。我的经验是tar.gz的CPU消耗更大，线程数可以适当增加，但不要超过CPU核心数的2倍。

6.5 异常重试机制

如果某个文件压缩失败，比如因为文件被占用或者磁盘临时满，可以加入重试机制。我的做法是失败的文件放入一个重试队列，等所有任务完成后，对重试队列里的文件再跑一轮，最多重试3次。

ConcurrentLinkedQueue<File> retryQueue = new ConcurrentLinkedQueue<>(); // 任务失败时 retryQueue.add(file); // 主线程被唤醒后 int retryCount = 0; while (!retryQueue.isEmpty() && retryCount < 3) { // 重新提交重试队列里的任务 retryCount++; }

这个机制在实际生产环境里非常有用，因为文件被占用、磁盘临时满这类问题是 transient 的，重试一次往往就能成功。

6.6 线程池的监控与动态调整

ThreadPoolExecutor提供了一些方法可以监控线程池状态，比如getActiveCount()获取活跃线程数，getQueue().size()获取队列长度。可以起一个定时任务，每隔几秒打印一次这些指标，观察线程池是否健康。

如果发现队列一直很长、活跃线程数一直等于最大线程数，说明线程数不够，可以动态调大maximumPoolSize。如果发现活跃线程数一直很低、队列也很短，说明线程数过多，可以调小。

ScheduledExecutorService monitor = Executors.newSingleThreadScheduledExecutor(); monitor.scheduleAtFixedRate(() -> { System.out.println("活跃线程: " + executor.getActiveCount()); System.out.println("队列长度: " + executor.getQueue().size()); System.out.println("已完成任务: " + executor.getCompletedTaskCount()); }, 0, 5, TimeUnit.SECONDS);

这个监控在实际排查性能问题时非常有用，强烈建议加上。

6.7 与NIO的结合

传统的FileInputStream和FileOutputStream是阻塞IO，每个线程在读写时都会阻塞。如果换成FileChannel，可以用更少的线程处理更多的文件。不过ZipOutputStream是基于OutputStream的，要结合NIO得自己实现WritableByteChannel的适配器，复杂度较高。

我的建议是：除非你的场景对性能有极致要求，否则用传统的阻塞IO就够了。线程池已经能带来数倍的提升，NIO的额外提升有限，但代码复杂度大幅增加，性价比不高。

6.8 实际项目中的取舍

在实际项目里，我不会把线程数设得太激进。因为压缩任务通常只是系统的一个功能模块，不能把CPU和IO资源全占了，否则会影响其他业务。我的做法是给线程池设一个合理的上限，比如最多8个线程，并且用CallerRunsPolicy做降级。

另外，压缩任务最好异步化，不要让用户请求线程等待。用户提交压缩请求后立即返回一个任务ID，后台线程池慢慢压，用户通过任务ID查询进度。这样用户体验更好，系统也更稳定。

这个方案后续还可以扩展的方向包括：支持断点续压（压缩中断后能从上次的位置继续）、支持加密压缩（用ZipOutputStream的加密功能）、支持多目标格式（根据用户选择输出zip或tar.gz）。这些扩展都不难，核心的并行框架不用动，只需要在压缩逻辑上做文章。

我个人在实际操作中的体会是：线程池和CountDownLatch的组合是Java并发编程里最实用的模式之一，不仅适用于压缩，还适用于批量图片处理、批量数据导出、批量文件上传等场景。把这个模式吃透，很多批量处理的需求都能套用。关键是要理解每个参数背后的含义，不要照抄网上的配置，要根据自己的硬件和业务特点去调优。踩过几次坑之后，你会对线程池的行为有更直观的感受，调参也会越来越有手感。