Java 處理海量 PDF 文件：多線程還是分散式？架構選型指南

場景：需從數萬份 PDF（每份約 200 頁）提取特定資料，單檔處理邏輯已跑通，現面臨批量化、高效率、穩定性三大挑戰。

為什麼單機多線程不是最佳解？

• 記憶體壓力：PDF 解析庫（PDFBox、iText、Apache Tika）載入 200 頁 PDF 易佔用數百 MB 堆內存，幾十線程並發直接 OOM
• CPU 密集 + IO 密集混合：解析計算密集，磁盤讀寫 IO 密集，線程池難平衡
• 單點故障：一台機器掛掉、磁盤滿、網路抖動，整個任務全軍覆沒
• 擴展性受限：物理核心數固定，無法線性擴展吞吐

推薦架構：分散式任務佇列 + Worker 集群

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  任務生產者  │────▶│  訊息佇列   │◀───▶│  Worker 集群 │
│  (掃描文件   │     │  (Kafka/    │     │  (多台機器， │
│   產生任務)  │     │   RabbitMQ, │     │   每台多線程)│
└─────────────┘     │   Redis)    │     └─────────────┘
                    └─────────────┘            │
                           │                   ▼
                    ┌─────────────┐     ┌─────────────┐
                    │  結果存儲   │◀────│  監控/重試  │
                    │  (DB/ES)    │     │  (死信佇列) │
                    └─────────────┘     └─────────────┘

關鍵組件選型

單機優化（若必須單機）

1. 流式解析：PDFBox PDFTextStripper.setSortByPosition(true) + 分頁處理，避免全文載入
2. 有界線程池：new ThreadPoolExecutor(cores, cores, 0, TimeUnit.SECONDS, new LinkedBlockingQueue<>(100)) 防止任務堆積 OOM
3. 檔案分批：每批 100-500 檔，完成一批釋放記憶體再處理下一批
4. 斷點續傳：資料庫記錄 file_id, status, page_progress，支援中斷恢復
5. 離峰執行：排程在業務低峰期運行，減少資源爭搶

成本效益建議

• 文件 < 5,000 份：單機優化 + 定時任務即可
• 5,000 - 50,000 份：2-3 台 Worker 機器 + Redis 佇列，成本可控
• > 50,000 份 / 持續增長：K8s + Kafka + 自動擴縮容，投資平台化

核心觀點：**「多線程」是戰術手段，「分散式任務佇列」才是戰略架構**。對於「數萬份 200 頁 PDF」這級別，請直接上分散式，避免在單機調優上耗盡工程預算。