Windows DLL Loader Lock：Rust JNI 執行緒如何讓 JVM 掛起
QuestDB Engineering Blog · 2026-05-19
QuestDB 工程團隊詳細記錄了一個在 Windows 上復現的死鎖問題：Rust 執行緒在 TLS（Thread Local Storage）析構期間持有 Loader Lock，同時等待 JVM 的 GC Safepoint，而 GC 又因為新執行緒無法取得 Loader Lock 而卡死。這個四方循環在特定時機下必然觸發，且完全沉默——沒有崩潰，只有永久掛起。
問題機制
Windows Loader Lock 是一個全進程互斥鎖，OS 在執行緒退出時持有它以執行 TLS 析構函式。Rust 的 jni-rs crate 預設在 TLS 析構時自動將執行緒從 JVM 分離，這觸發了 JVM 的 Safepoint 檢查。死鎖的四個節點如下：
- Rust 執行緒持有 Loader Lock，等待 JVM Safepoint
- JVM GC 等待所有執行緒到達 Safepoint
- GC 等待新的 Java 執行緒
- 新 Java 執行緒初始化需要 Loader Lock——已被 Rust 執行緒持有
四者形成一個閉合等待環，任何一方都不會超時，也不會主動中斷。
診斷過程
團隊使用了三個工具組合才找到根本原因：ProcDump 擷取全記憶體 dump、WinDbg 分析 native stack、jhsdb 從 dump 中提取 Java stack。突破口是開啟 JVM 的 Safepoint timeout 日誌，看到 "Timed out while spinning to reach a safepoint"，才確認 Rust 執行緒是阻塞 GC 的那一方。
修復方式
解法是放棄依賴 TLS 析構的自動 detach 機制，改用 Tokio 的 on_thread_stop callback 在執行緒仍處於「正常狀態」（Loader Lock 尚未取得）時主動呼叫 jni-rs 的顯式 detach。時序上：on_thread_stop 在 OS 取得 Loader Lock 之前執行，JVM detach 完成後執行緒才進入 TLS 析構流程，等待鏈徹底消除。
OpenBSD 7.9 發布：pledge 新系統呼叫、ML-KEM 量子安全 TLS 與 SMP 改進
openbsd.org · 2026-05-19
OpenBSD 7.9 於 2026 年 5 月 19 日發布，帶來核心安全機制的擴充（新 pledge syscall）、量子安全 TLS keyshare 支援，以及多項 SMP 並發效能改進。
核心安全改動
本版本引入 __pledge_open(2) 系統呼叫，讓 libc 能在 pledge 沙箱內存取受管控的內部檔案，同時移除 pledge 的 tmppath promise，強制使用更安全的替代方案。unveil(2) 對掛載點的檔案系統處理也得到改善，確保沙箱邊界在 mount 操作下不洩漏。
LibreSSL 4.3.0 與量子安全 TLS
LibreSSL 4.3.0 新增 ML-KEM768_X25519 TLS keyshare 支援，這是混合式金鑰交換機制：結合經典橢圓曲線（X25519）與後量子密碼學（ML-KEM，基於 CRYSTALS-Kyber），在 TLS 握手中同時提供前向保密與量子抵抗性。同捆的 OpenSSH 10.3 包含多項安全修補與新功能。
核心並發與排程改進
核心互斥鎖的 CAS spinlock 已被替換為 "parking" 鎖，減少高競爭場景下的空轉耗電。排程器新增 hw.blockcpu sysctl 以管理不同速度的 CPU core（heterogeneous core 支援基礎），同時實現非鎖定 socket splicing 與平行 page fault 處理，改善多核心 I/O 密集工作負載效率。
硬體支援
- nhi(4)：USB4 控制器驅動
- sgmsi(4)：Sophgo SG2042 RISC-V 平台
- smtgpio(4)：SpacemiT K1
- arm64：RK3588/RK3576 SoC 與 Apple Silicon 控制器擴充支援
- 802.11ax（Wi-Fi 6）基礎無線 stack 支援