Big Sur系统下JavaScriptCore堆崩溃的调试方法与防护方案咨询

该类崩溃是macOS Big Sur对JavaScriptCore的异步GC（垃圾回收）时序调整导致的桥接对象野指针问题：你暴露给JSContext的PluginWindow实例在OC侧被提前释放，而JavaScriptCore的后台Heap Helper线程还在扫描该桥接对象的内存地址，访问无效地址触发EXC_BAD_ACCESS、EXC_I386_GPFLT错误，低地址错误（如0x18）是典型的已释放OC对象isa指针访问异常的特征。

• 统一管控桥接对象生命周期：不要在窗口关闭时直接释放PluginWindow实例，新增和JSVirtualMachine绑定的存活对象池，所有暴露给JS的OC对象都先加入对应VM的对象池，等JSVirtualMachine完全销毁后再统一清空池内对象，保证桥接对象生命周期长于JSGC的执行周期
• 主动清理JSContext引用：销毁JSContext前，先把所有注入到上下文的全局对象（如你的App对象、htmlWindow实例）显式置空：

// 销毁前执行
self.context[@"App"] = nil;
// 遍历所有注入的全局属性逐一置空

同时不要在主队列异步执行context销毁逻辑，确保所有evaluateScript执行完成后再执行销毁操作，可给JSVirtualMachine增加2~3秒的延迟释放逻辑，给GC留够异步执行的窗口

• 新增桥接代理层：不要直接把NSPanel子类暴露给JS，新增无状态的代理类作为JS和实际UI对象的中间层，代理层只持有PluginWindow的弱引用，所有JS调用先经过代理层判断弱引用是否有效，无效直接返回空值，窗口关闭时先把代理层的弱引用置空，彻底切断JS侧对已释放UI对象的访问路径
• 增加野指针防护：线上环境可接入OC野指针监控组件，对已释放对象的访问直接做容错处理，避免触发崩溃

• 调整GC执行模式：在Xcode Scheme的环境变量中新增JSC_gcConcurrency = 0，将异步GC改为同步执行，崩溃会直接触发在当前执行的代码栈，而非随机的后台辅助线程，方便定位触发时机
• 开启内存调试选项：Xcode Scheme -> Diagnostics 页勾选Zombie Objects、Malloc Scribble、Malloc Stack Logging，崩溃时会直接输出被访问的已释放对象的类名、分配栈，确认是否是PluginWindow提前释放导致的问题
• 时序断点验证：给-[JSVirtualMachine dealloc]、-[PluginWindow dealloc]、-[JSContext dealloc]添加断点，验证执行顺序是否符合预期：正确顺序是JSContext dealloc -> JSVirtualMachine dealloc -> PluginWindow dealloc，如果PluginWindow的释放早于JSVM释放即可确认是生命周期时序问题
• 最小复现验证：剥离其他业务逻辑，只保留「创建VM -> 创建Context -> 注入桥接对象 -> 初始化PluginWindow -> 销毁Context -> 释放PluginWindow -> 销毁VM」的核心流程，循环执行快速复现问题，验证修复方案的有效性

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