Swift报错"EXC_BAD_ACCESS"？内存管理的ARC原理深度解析
在iOS/macOS开发中，EXC_BAD_ACCESS是开发者最常遭遇的崩溃类型之一，其本质是非法内存访问。当程序试图访问已释放的对象、未初始化的指针或越界的数组时，系统会触发此错误。本文结合CSDN社区的实战案例，深度解析Swift内存管理机制（ARC）与该错误的关联，并提供可落地的解决方案。
一、EXC_BAD_ACCESS的核心根源
1. 典型触发场景
| 场景类型 | 触发条件 | 示例代码 | 崩溃特征 |
|---|---|---|---|
| 数组越界访问 | 索引超出数组长度 | let arr = [1, 2, 3]; print(arr[5]) | EXC_BAD_ACCESS (code=1, address=0x...) |
| 指针悬垂 | 对象释放后仍访问 | var obj: MyClass? = MyClass(); obj = nil; print(obj!.name) | 访问已释放对象的内存地址 |
| 循环引用 | 强引用循环导致对象未释放 | 循环引用代码示例 | 内存泄漏后访问无效地址 |
| 多线程竞争 | 线程A释放对象，线程B同时访问 | 并发修改数组场景 | 竞态条件导致崩溃 |
2. ARC机制的局限性
Swift的自动引用计数（ARC）通过跟踪对象引用实现内存管理，但存在两大缺陷：
- 无法检测越界访问：ARC仅管理对象生命周期，不校验数组索引合法性
- 弱引用隐蔽性：
weak变量在对象释放后自动置nil，但若直接访问非可选类型指针（如unowned），会导致EXC_BAD_ACCESS
二、实战案例分析
案例1：图片浏览器的数组越界
class ImageBrowser {
private var cache: [UIImage?] = Array(repeating: nil, count: 10)
private var currentIndex = 0
func loadImage(at index: Int) -> UIImage? {
// 错误1：未检查数组越界
return cache[index]
}
func cacheImage(_ image: UIImage, at index: Int) {
// 错误2：未处理索引溢出
cache[index] = image
currentIndex = index
}
func showNextImage() {
// 错误3：未处理循环索引时的越界
let nextIndex = currentIndex + 1
let image = loadImage(at: nextIndex)
// ...渲染逻辑
}
}崩溃日志：
Thread 1: EXC_BAD_ACCESS (code=1, address=0x100000018)
0 ImageBrowser 0x0000000100001234 loadImage(at:) + 48
1 ImageBrowser 0x0000000100001567 showNextImage() + 76解决方案：
