NSDateFormatter调用date(from:)偶发EXC_BAD_ACCESS崩溃问题求助

• 核心诱因：高并发场景下频繁创建DateFormatter触发ICU内部资源竞争/野指针
  你当前的实现每次调用longYearFormatter都会创建一个新的DateFormatter实例，而你的崩溃发生在全局默认优先级队列（com.apple.root.default-qos），属于后台并发队列。iOS 13~15版本存在已知的底层ICU库bug：当短时间内在多线程下大量创建/销毁带时区格式符的DateFormatter时，会导致内部持有的Calendar对象提前释放，访问时触发EXC_BAD_ACCESS，和你上报的崩溃栈完全吻合。这类并发bug属于概率触发，本地测试并发量不足时很难复现，和地区、语言、12/24小时制设置无关，也解释了你为什么无法在模拟器复现问题。
• 次要可能性：异常入参触发边界case
  虽然你提供的示例dateString格式匹配yyyy-MM-dd'T'HH:mm:ssZZZZ，但如果线上存在不符合预期的特殊字符、时区格式异常的入参，也有可能触发ICU解析逻辑的边界bug，导致内部内存访问错误。
• 隐蔽问题：DateFormatter属性并发修改问题
  如果你的项目中存在其他地方复用该扩展创建的DateFormatter、并且在多线程下修改它的dateFormat、timeZone等属性，也会触发底层ICU资源的并发访问崩溃。

• 改用单例模式复用DateFormatter实例，避免频繁创建销毁：由于你已经设置了固定的en_US_POSIX locale，完全可以全局复用同一个实例，修改timeZone属性时加锁保证线程安全即可，大幅降低触发底层bug的概率。
• 优化格式符适配性：可以将ZZZZ替换为适配性更强的ZZZZZ匹配时区偏移格式，同时添加dateString格式预校验逻辑，避免异常格式传入触发底层bug。
• 高并发场景下替换为ISO8601DateFormatter：iOS 10+支持的ISO8601DateFormatter是原生线程安全的实现，专门用来解析这类标准ISO时间格式，稳定性远高于自定义DateFormatter。

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