PHP-FPM 過載後無法恢復根因分析：eAccelerator 自旋鎖在共享記憶體中被孤立持有導致全進程阻塞

核心證據：eAccelerator 源碼中的自旋鎖實現

eAccelerator 使用共享記憶體實現進程間鎖 (mm_mutex)，採用 x86 原子指令自旋鎖：

// 簡化版 eAccelerator 共享記憶體自旋鎖
#define spinlock_try_lock(rw) \
    asm volatile("lock ; decl %0" : "=m" ((rw)->lock) : : "memory")
#define _spinlock_unlock(rw) \
    asm volatile("lock ; incl %0" : "=m" ((rw)->lock) : : "memory")

static int mm_do_lock(mm_mutex* lock, int kind) {
    while (1) {
        spinlock_try_lock(lock);           // 原子遞減嘗試獲取
        if (lock->lock == 0) {             // 獲取成功 (lock 變為 0)
            lock->pid = getpid();
            lock->locked = 1;
            return 1;
        }
        _spinlock_unlock(lock);            // 獲取失敗，釋放並讓出 CPU
        sched_yield();
    }
    return 1;
}

static int mm_do_unlock(mm_mutex* lock) {
    if (lock->locked && (lock->pid == getpid())) {
        lock->pid = 0;
        lock->locked = 0;
        _spinlock_unlock(lock);            // 原子遞增釋放
    }
    return 1;
}

致命場景重現

1. 進程 A 進入 mm_do_lock，成功獲取鎖 (lock->lock == 0，設定 pid=A, locked=1)。
2. 進程 A 執行 require_once 載入腳本，編譯緩存操作耗時較長。
3. 超過 5 秒，PHP-FPM Master 發送 SIGTERM 強制殺死進程 A。
4. 關鍵點：進程 A 被強殺，**無機會執行 mm_do_unlock**，鎖狀態永久保持 locked=1, pid=A。
5. 進程 B、C、D... 陸續接收請求，嘗試 require_once，進入 mm_do_lock。
6. 發現 lock->lock != 0 (實際為負數，因原子遞減未配對遞增)，進入無限 while(1) 自旋 + sched_yield()。
7. 所有工作進程 100% CPU 空轉，無法處理任何請求。

GDB 現場鑑證確認

(gdb) p *mm->lock
$8 = {lock = 4294966693, pid = 21775, locked = 1}

; php-fpm.conf
request_terminate_timeout = 300s ; 或 0 (關閉，交由應用層控制)

function __autoload($class) {
    if (microtime(true) - $_SERVER['REQUEST_TIME_FLOAT'] > 4.5) { // 接近 5 秒
        exit('Autoload timeout protection'); // 主動退出而非被強殺
    }
    // 正常載入邏輯
}