Java PDF 下載緩慢：解密過程佔用大量時間的優化策略

問題現象

下載加密 PDF 時，伺服器端需先解密再輸出，解密耗時導致下載極慢甚至逾時。

可能原因排查

1. 演算法選擇不當：自行實作的加密/解密（如簡易 XOR、自訂 RSA）效率極低；應改用標準庫（AES-GCM、ChaCha20-Poly1305）。
2. 鑰匙派生過重：每次下載皆用 PBKDF2/Argon2 高迭代次數導出金鑰，建議快取派生金鑰或使用金鑰包裹機制。
3. 串流處理缺失：一次性將整個檔案讀入記憶體解密再寫出，造成 GC 壓力與 OOM。應使用 CipherInputStream 邊讀邊解邊寫。
4. 檔案過大：超過數百 MB 的 PDF 若無分塊下載（Range Request），單一連線傳輸時間本身就長。

優化方案

1. 串流式解密（核心）

try (InputStream in = new FileInputStream(encFile);
     CipherInputStream cis = new CipherInputStream(in, cipher);
     OutputStream out = response.getOutputStream()) {
    byte[] buf = new byte[8192];
    int len;
    while ((len = cis.read(buf)) != -1) {
        out.write(buf, 0, len);
    }
    out.flush();
}

CipherInputStream 內部以緩衝區方式處理，記憶體佔用恆定。

2. 非對稱加密改用混合加密

• 檔案本體用 AES-256-GCM 隨機金鑰加密（快）。
• 隨機金鑰再用 RSA/OAEP 或 ECIES 加密儲存（小）。
• 下載時只需解密小金鑰，再高速串流解密檔案。

3. 啟用 HTTP Range 請求支援斷點續傳

配合 Content-Range、Accept-Ranges: bytes，前端可多執行緒下載，體感速度大增。

4. 非同步預解密 / 快取

• 熱門檔案可在上傳後背景預先解密暫存明文（或解密後的緩衝區），下載時直接輸出。
• 使用 Redis/本地快取儲存派生金鑰，避免重複 KDF 運算。

效能基準建議

除錯步驟

1. 用 jcmd PID JFR.start 或 VisualVM 取樣 CPU，確認熱點在 Cipher.doFinal 或 KDF。
2. 測試單獨解密 100 MB 檔案耗時，若 > 2 秒即為演算法/實作問題。
3. 檢查 JVM 參數 -XX:+UseAES -XX:+UseAESIntrinsics 是否啟用（預設開啟）。