Swift协议类型集合中结构体的引用语义与ARC内存泄漏解析

问题 #

解码JSON对象时遇到内存泄漏问题，排除JSONDecoder本身问题，复现代码如下：

struct AccountResponse: Codable {
    var accounts: [Account]?
}

struct Account: Codable {
    var id: String?
    var openedDate: Date?
}

protocol AccountProtocol {
    var id: String? { get }
    var openedDate: Date? { get }
}

extension Account: AccountProtocol {}

class ViewController: UIViewController {
    override func viewDidLoad() {
        test()
        super.viewDidLoad()
    }
    
    var userAccounts: [AccountProtocol]?
    
    func test() {
        let data = 
        """
        {
          "accounts": [{
            "id": "2028658397",
            "openedDate": "2020-05-06T00:00:00Z"
          }]
        }
        """.data(using: .utf8)!
        
        let decoder = JSONDecoder()
        decoder.dateDecodingStrategy = .iso8601
        self.userAccounts = (try! decoder.decode(AccountResponse.self, from: data)).accounts
    }
}

使用Instruments的Leaks工具分析时，持续检测到内存泄漏。但执行以下任一操作，泄漏会消失：

• 将userAccounts数组的类型从协议改为具体类型[Account]
• 将struct Account改为class
• 将AccountResponse中的accounts声明从var改为let
• 将Date类型的属性改为String

请问：当集合中的元素是实现了协议的结构体时，引用语义是如何工作的？结合协议类型集合的工作机制，这些修复方案背后的ARC逻辑是什么？

分析与解答 #

一、协议类型集合的内存工作机制 #

Swift里的协议类型属于存在类型（Existential Type），当值类型（比如结构体）存入协议集合时，Swift会自动把结构体包装在一个**存在性容器（Existential Container）**中。这个容器是引用类型，内部不仅持有结构体的副本，还会存储协议相关的元数据（类型信息、方法表等），用于实现协议的动态派发。

核心矛盾在于：值类型本身不需要ARC管理，但包装它的存在性容器是引用类型，会纳入ARC的引用计数体系。当结构体存在可变属性或包含特定类型的子属性时，容器和结构体的内部存储可能形成隐蔽的循环引用，导致内存泄漏。

二、各修复方案的ARC逻辑解析 #

1. 改用具体类型[Account]存储
   当集合类型从[AccountProtocol]改为[Account]，就不再需要存在性容器，直接存储值类型的结构体实例。值类型的内存由编译器自动在栈或堆上分配/释放，完全不依赖ARC的引用计数机制，自然不会产生泄漏。

2. 将Account从结构体改为类
   类本身是引用类型，存入协议集合时，存在性容器持有的是类实例的引用（而非值副本）。此时容器和实例的引用关系是单向的：容器持有实例，当容器被销毁时，实例的引用计数减1，不存在循环引用的条件，内存可以正常释放。

3. 将AccountResponse.accounts改为let
   当accounts是不可变的let属性时，解码得到的数组和内部的Account结构体都是不可变状态。Swift在包装不可变结构体到存在容器时，不会生成支持可变操作的间接引用层，避免了因可变绑定产生的循环引用。而原来的var属性会触发编译器生成额外的引用包装，这个包装和存在容器可能形成循环，导致内存无法回收。

4. 将Date属性改为String
Date虽然是值类型，但部分平台的底层实现可能包含引用类型的内部存储；而Swift的String采用写时复制（COW）机制，内存管理更高效且不会产生额外的绑定引用。当结构体包含Date时，包装到存在容器时，Date的内部引用可能和容器形成循环；换成String后，COW机制避免了这种额外的引用关联，消除了泄漏条件。

内容的提问来源于stack exchange，提问作者sleepcha