昨天有位開發者在 Github 上給我提了一個 issue，裡面指出 OSSpinLock 在新版 iOS 中已經不能再保證安全了，並提供了幾個相關資料的鏈接。我仔細查了一下相關資料，確認了這個讓人不爽的 bug。

OSSpinLock 的問題

2015-12-14 那天，swift-dev 郵件列表裡有人在討論 weak 屬性的線程安全問題，其中有幾位蘋果工程師透露了自旋鎖的 bug，對話內容大致如下：

新版 iOS 中，系統維護了 5 個不同的線程優先級/QoS: background，utility，default，user-initiated，user-interactive。高優先級線程始終會在低優先級線程前執行，一個線程不會受到比它更低優先級線程的干擾。這種線程調度算法會產生潛在的優先級反轉問題，從而破壞了 spin lock。

具體來說，如果一個低優先級的線程獲得鎖並訪問共享資源，這時一個高優先級的線程也嘗試獲得這個鎖，它會處於 spin lock 的忙等狀態從而占用大量 CPU。此時低優先級線程無法與高優先級線程爭奪 CPU 時間，從而導致任務遲遲完不成、無法釋放 lock。這並不只是理論上的問題，libobjc 已經遇到了很多次這個問題了，於是蘋果的工程師停用了 OSSpinLock。

蘋果工程師 Greg Parker 提到，對於這個問題，一種解決方案是用 truly unbounded backoff 算法，這能避免 livelock 問題，但如果系統負載高時，它仍有可能將高優先級的線程阻塞數十秒之久；另一種方案是使用 handoff lock 算法，這也是 libobjc 目前正在使用的。鎖的持有者會把線程ID 保存到鎖內部，鎖的等待者會臨時貢獻出它的優先級來避免優先級反轉的問題。理論上這種模式會在比較復雜的多鎖條件下產生問題，但實踐上目前還一切都好。

libobjc 裡用的是 Mach 內核的 thread_switch() 然後傳遞了一個 mach thread port 來避免優先級反轉，另外它還用了一個私有的參數選項，所以開發者無法自己實現這個鎖。另一方面，由於二進制兼容問題，OSSpinLock 也不能有改動。

最終的結論就是，除非開發者能保證訪問鎖的線程全部都處於同一優先級，否則 iOS 系統中所有類型的自旋鎖都不能再使用了。

OSSpinLock 的替代方案

為了找到一個替代方案，我做了一個簡單的性能測試，對比了一下幾種能夠替代 OSSpinLock 鎖的性能。測試是在 iPhone6、iOS9 上跑的，代碼在這裡。我嘗試了不同的循環次數，結果並不都一樣，我猜這可能是與 CPU Cache 有關，所以這個結果只能當作一個定性分析。

可以看到除了 OSSpinLock 外，dispatch_semaphore 和 pthread_mutex 性能是最高的。有消息稱，蘋果在新系統中已經優化了 pthread_mutex 的性能，所以它看上去和 OSSpinLock 差距並沒有那麼大了。

開源社區的反應

蘋果

查看 CoreFoundation 的源碼能夠發現，蘋果至少在 2014 年就發現了這個問題，並把CoreFoundation 中的 spinlock 替換成了 pthread_mutex，具體變化可以查看這兩個文件：CFInternal.h(855.17)、CFInternal.h(1151.16)。蘋果自己發現問題後，並沒有更新OSSpinLock 的文檔，也沒有告知開發者，這有些讓人失望。

Google

google/protobuf 內部的 spinlock 被全部替換為 dispatch_semaphore，詳情可以看這個提交：https://github.com/google/protobuf/pull/1060。用 dispatch_semaphore 而不用 pthread_mutex 應該是出於性能考慮。

其他項目

因為 OSSpinLock 出現這種問題的幾率很小，也沒有引起很大的重視，我所能找到的也只有 ReactiveCocoa 在討論這個問題。

相關鏈接

https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000344.html

http://mjtsai.com/blog/2015/12/16/osspinlock-is-unsafe/

http://engineering.postmates.com/Spinlocks-Considered-Harmful-On-iOS/

https://twitter.com/steipete/status/676851647042203648