当存储空间不足时，从 iPhone 或 iPad 中删除文件是释放存储空间最简单的方法之一。然而，有时你可能会发现在 iPhone 或 iPad 上删除文件很困难。为了帮助你轻松删除文件，我们在本文中

背景 继 1 月做空机构 CapitalWatch 指控 AppLovin 深度涉入洗钱网络、关联东南亚 “杀猪盘” 后，这场资本风波的余震仍在持续。最新市场数据显示，截至 2026 年 2 月 5

以下是 Objective-C 中 RunLoop 的高频面试问题清单，涵盖基础概念、原理机制、线程关系、应用场景及实战排查，适用于中高级 iOS 开发岗位面试： 🔹 一、基础概念类 Q1：RunLo

在大型 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） 。 它的模型本质上是一个 “生产者-消费