Objective-C

在大型 iOS 工程中，设计锁粒度与隔离策略的目标是在数据安全性、执行性能与开发维护成本之间找到平衡。锁粒度过粗会导致主线程卡顿（如你提供的 slowlog_0 所示），锁粒度过细则会增加死锁风险。

这是一个非常经典且容易在面试中遇到的问题。在 iOS 开发中，执行 dispatch_sync(dispatch_get_main_queue(), ^{ ... }); 会产生立即且永久的死锁。 这

“双锁反序”（AB-BA Deadlock）是多线程开发中最经典的死锁模型。当两个线程以相反的顺序请求两把相同的锁时，就会形成环路等待。 1. 场景描述 线程 1：已经持有 锁 A，正在尝试获取 锁

weak 引用表的同步机制是 Objective-C Runtime 中设计最精巧的部分之一，它必须在“高频访问”、“内存节省”和“多线程安全”之间取得平衡。 其核心设计可以概括为：多级哈希表结构 +

在 ARC（Automatic Reference Counting）环境下，retain 和 release 看起来只是简单的加减计数，但由于它们必须是线程安全的，其实内部逻辑非常复杂，涉及到多层级

在 Objective-C 中，atomic 属性的实现并不是绝对意义上的“线程安全”。 简单来说，atomic 只能保证属性的 Setter 和 Getter 操作本身是原子的（即读写完整），但无法

Objective-C Runtime（libobjc）作为一个高度动态且线程安全的系统，其内部大量使用了不同类型的锁来保护全局表、方法缓存和类结构。 了解这些内部锁，能帮你理解为什么有些看起来简单的

“不公平”（Unfair）在这里是一个计算机科学术语，主要指该锁不保证“先来后到”的排队顺序（First-In-First-Out, FIFO） 。 在传统的“公平锁”中，如果线程 A、B、C 依次尝

os_unfair_lock 是苹果在 iOS 10 中推出的 OSSpinLock 直接替代品。它能够规避优先级反转问题，核心在于它彻底改变了等待机制，并与内核调度器（Mach Kernel）进行了

在自旋锁（Spinlock）中，优先级反转（Priority Inversion） 并非传统意义上的“多个线程竞争”，而是一种由于“忙等”机制导致的死锁状态。 其产生的核心逻辑如下： 1. 产生的前提

OSSpinLock 被废弃的真实原因在于它在 iOS 的线程调度机制下存在严重的 优先级反转（Priority Inversion） 风险，这会导致应用出现逻辑上的死锁或永久性卡顿。 虽然从代码逻辑

在使用 dispatch_semaphore（信号量）时，最隐蔽且最常见的死锁类型是**“优先级反转导致的线程饥饿死锁”**，尤其是在 iOS 这种具有复杂优先级调度机制的系统中。 以下是该类死锁的详

本质区别可以总结为：Mutex 是“所有权制”，而 Semaphore 是“信号制”。 1. 所有权 (Ownership)：谁领的证，谁能离 这是两者最根本的区别。 Mutex（互斥锁）： 具有 O

在工程实践中，由于 dispatch_semaphore（信号量）不具备 Ownership（所有权） ，它就像是一把“没有主人的锁”。这虽然提供了灵活性，但也直接导致了两个极具杀伤力的风险：优先级反

在并发编程的语境下，虽然我们经常把 dispatch_semaphore 当作锁来用（比如信号量设为 1），但从设计哲学和底层语义来看，它确实不是严格意义上的“锁”。 主要原因在于它缺乏锁的两个核心属

NSConditionLock 是对 NSCondition 的进一步封装。它最大的特点是：它不仅是一把锁，还自带一个“整数状态值（Condition Value）”。 在工程中，它最适合解决的是**

NSCondition 封装了 POSIX 线程（pthread）中的两个核心原语：互斥锁（Mutex） 和 条件变量（Condition Variable） 。 它的模型本质上是一个 “生产者-消费

相比于普通的互斥锁（Mutex），递归锁（Recursive Mutex） 的核心区别在于它允许“锁的所有者”多次进入而不死锁。为了实现这一点，它必须在底层内存中维护普通锁所没有的额外状态信息。 在

在高性能锁的设计中，Adaptive Spinning（自旋自适应） 是一种混合策略，旨在平衡“空转等待”的低延迟和“挂起线程”的低功耗。 简单来说，它让 pthread_mutex 变得“聪明”了：

从层级结构上来说，NSLock 是对 pthread_mutex 的 面向对象封装。虽然它们最终都指向底层的内核同步原语，但在性能、功能和使用场景上有着显著的差异。 1. 抽象层级的差异 pthrea