Objective-C

在工程实践中，由于 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

虽然 @synchronized 在易用性上拿到了满分，但它的性能在 iOS 各类锁中通常排在末尾。其性能瓶颈并非来自单一原因，而是源于从语言层到底层硬件的“多重收税” 。 1. 全局竞争层：哈希桶冲

@synchronized 之所以天然支持递归（即同一个线程可以多次获取同一把锁而不会导致死锁），是因为它在底层使用了 递归锁（Recursive Mutex） ，并且配合了**嵌套计数（Nestin

这个问题直指 @synchronized 底层的实现逻辑。简单来说，因为它遵循了 Objective-C 的 “向 nil 发送消息不执行操作” 以及 “基于对象地址查找锁” 的原则。 如果传入的是

在 objc_sync_enter 的底层实现中，Objective-C 并没有为每个对象直接分配一个锁（那太浪费内存了），而是采用了一种全局哈希映射的机制。 它的核心逻辑可以概括为：通过对象的内存地

在 Objective-C 中，@synchronized(obj) 是最易用的同步手段，但它其实是一个高度封装的语法糖。在编译期，编译器会将它展开为一对特殊的函数调用，并配合异常处理机制来确保锁的释

CAS（Compare-And-Swap）虽然是无锁编程的基石，但它有一个致命的逻辑漏洞：它只检查“值”是否相等，而不检查“值”是否被改动过。 1. 为什么会产生 ABA 问题？ CAS 的逻辑是：

在单线程世界里，编译器和 CPU 遵循 “不影响最终执行结果（As-if-serial）” 的原则进行优化。但在多线程环境下，这种“自作聪明”的优化（指令重排）极易导致临界区（Critical Sec

False Sharing（伪共享） 是多核编程中一个极其隐蔽的性能杀手。它发生在这种场景：两个完全无关的变量，因为恰好被编译器或分配器放到了同一个 Cache Line（缓存行） 中，导致本应并行的

在多核编程中，锁（Lock）只是上层的抽象，而 CPU Cache 与 MESI 协议 则是底层执行的真实现场。它们之间的互动决定了锁竞争的性能瓶颈。 简单来说：锁竞争的本质，就是多个 CPU 核心抢

实际上，互斥（Mutual Exclusion）只解决了“谁能改”的问题，而可见性（Visibility）解决了“改了之后别人能不能看见”的问题。 如果只考虑互斥而忽略可见性，即便你的代码加了锁，依然

在 NSInvocation 的生命周期中，forwardInvocation: 是最后也是最强大的堡垒。它允许一个对象在“完全不知道如何处理某个方法”的情况下，依然能优雅地接管这个请求。 在真实项目

在 Objective-C 的世界里，NSInvocation 是一个非常强大但底层的存在。简单来说，它是对“消息转发”过程的一种静态呈现。 以下是它解决的核心问题以及为什么在 Swift 的设计哲学

如果 forwardInvocation: 依然没有处理消息（即在该方法内部既没有改变 target 执行，也没有手动调用 invoke，甚至干脆是个空实现），那么消息转发流程将走到终点。 接下来会发