侯仕奇的博客

Data Race两个或多个线程在没有同步机制的情况下，同时访问同一个变量，并且至少一个线程在写数据。（竞态条件）是指程序的正确性依赖于多个线程的执行顺序，而这个顺序是不可控的。它未必会导致崩溃，但会导致逻辑错误或状态异常。Data Race 是导致崩溃的“并发毒瘤”，而 Race Condition 是设计中的“逻辑地雷”。在日常 iOS 多线程开发中，保持警惕，对共享资源加锁，对状态流转做好保护，是避免这两类问题的根本办法。是否有多个线程访问同一个变量？

iOS 10引入的os_unfair_lock是Apple推荐的高性能轻量级锁，相比OSSpinLock解决了优先级反转问题，采用阻塞等待而非自旋机制。本文详细解析其原理、使用方法及性能优势，对比OSSpinLock和pthread_mutex，平均延迟降低30%以上。文章还提供Swift封装示例和最佳实践，强调其不可递归特性及正确释放锁的重要性。适用于高性能计数、资源池管理等场景，是线程安全同步的理想选择。

getter 或 setter 调用能够“原子”地完成，也就是不会出现“撕裂读写”（torn read/write）或返回半更新状态；或者在新版 runtime 里，也可能用一把隐藏的 spin-lock（而非 @synchronized）来保护单次读/写。如果 didFailedRequest 可能在任何线程被调用, 怎样确保 Checking 过程的原子性?这样才能彻底杜绝在高并发场景下多个线程同时进入 Checking 流程的可能。：锁的粒度仅包裹在“单个属性存取”这一行代码里。

如果 didFailedRequest 可能在任何线程被调用, 怎样确保 Checking 过程的原子性 ?在多线程环境下， 如果在任意线程被并发调用，那么下面这段代码就会出现竞态条件（race condition）：两个线程 A、B 同时执行到 时，都可能看到 ，随后各自把它置为 YES，导致“Checking”流程被并发执行，破坏了原子性。最直观的方法，就是在检查和修改 时加锁。优点：语义清晰，容易理解； 性能优于 。缺点：如果“Checking”耗时较长，会频繁加锁解锁；锁的粒度、死锁等需

本文探讨了Objective-C中处理nonatomic属性线程安全的四种方法：1)使用@synchronized或NSLock锁；2)串行调度队列；3)C11原子布尔操作；4)原子属性配合锁。每种方案各有优劣：锁操作简单但性能较差，串行队列高效但需管理多队列，原子操作性能最好但实现较复杂。文章特别强调，单独使用atomic属性无法保证复合操作（检查+设置）的原子性，必须配合同步机制。最后建议根据需求选择方案，简单场景用锁，高性能场景用队列或原子操作。文中还解释了相关技术术语如"撕裂读取&quot

使用 Grand Central Dispatch (GCD) 实现多读单写的属性