1. 介绍
最近一直在做有关 JavaScriptCore 的技术需求，上周发现一个问题，当在JavaScriptCore 在垃圾回收时，项目会有一定几率发生崩溃。崩溃发生时调用堆栈如下：
图1 调用堆栈
先对上图中两个比较重要的堆栈过程做个说明：
图2 生成 JSValue
1、toJSValueInContext：方法是通过 JSObjectMake 再生成一个 JSValue。如上图中，最终返回的是一个 JSValue，并且这个 JSValue 对 self（ PHOValue 类型）做了一次强引用。
图3 该 JSValue 释放回调
2、PHOObject_finalizeCallback 是 JSValue 的析构函数，当通过 JSObjectMake 生成的 JS 对象在释放时会调用该函数。在这个函数中，我们释放了之前所强引用的 self（ PHOValue 类型）。
当 self 释放时，self 所强持有的对象A会被释放。进一步执行A的dealloc 方法中，在 dealloc 方法中，我们再次调用了JSObjectMake 函数生成其他的对象，并再次强持有了 A 对象，并将 JSValue 传入到 JS 中进行其他方法调用（如果不理解这个问题，请参考 JSPatch 对重写 dealloc 方法的处理，但是不同的是 JSPatch 并不依赖垃圾回收）。
为了说明问题，特地画了个内存流程简图辅助理解：
图4 内存情况和流程说明
2. 定位问题
为了定位问题，我们进行了很多猜想，在这里我们列举两个比较有代表性的猜想。
猜想1：在 dealloc 中不允许对正在执行 dealloc 的对象进行强引用
由于这个问题是有一定的概率出现，并且报出了 Thread 1: EXC_BREAKPOINT ( code = EXC_I386_BPT, subcode = 0x0 )这样的错误，因此我们最开始一直将精力集中在追查野指针上。
崩溃发生在 self 进行 dealloc 的时机，但是在这个时机我们对 self 又做了一次强引用（见图2代码）。此时会对 self 的引用计数 1，因此猜测可能会重复触发self 的 dealloc。但是实际上当崩溃发生时，po 操作查看 self，context 等参数，发现所有的参数都是正常允许访问的。
并且这与调用堆栈的现象并不相符，至少我们没有看到两次调用 dealloc。因此这种猜想是不成立的。
猜想2：JavaScriptCore 在进行垃圾回收时不允许进行 JSObjectMake
从调用堆栈来看，每次崩溃都发生在 JSObjectMake 之后，这是不是意味着垃圾回收时不能进行JSObjectMake操作呢？为了验证这个问题，我们在PHOObject_finalizeCallback 函数中不做任何对象释放操作，仅仅执行一次JSObjectMake，
图5 回调中调用 JSObjectMake
这样的改动就意味着，只要处于 JavaScriptCore 进行垃圾回收，就会立刻调用JSObjectMake。经过验证发现，果然在此处发生崩溃，并且是百分百复现，调用堆栈基本一致。因此可以说明我们的猜想是正确的。
仔细想想这个问题，有经验的同学可能会感到细思极恐，因为垃圾回收机制并不受我们控制，我们在进行 JSObjectMake 无法保证一定不处于垃圾回收期间，那么理论上来说应该进行发生崩溃才对，为什么这个问题之前一直没有暴露出来呢？
我们循环100000次创建对象并不断通过 safari 的调试功能人工触发垃圾回收，并没有发生崩溃。JavascriptCore 存在两种垃圾回收方式，一种是同步回收，一种是异步回收，无论哪种方式，JavascriptCore 对虚拟机有共有的堆（ Heap，JavascriptCore 的垃圾回收处理都在 Heap.cpp 中）都进行了加锁处理，换句话说就是在正常情况下 JSObjectMake 在垃圾回收时是无法访问堆的。
图6 JSCore的两种垃圾回收方式
而我们之所以发生崩溃是由于我们在对象在垃圾回收的回调中访问了堆，这个问题的伪代码如下：
图7 伪代码
3. 寻找解决方案
既然基本定位到了问题的原因，那么下一步就要找方法去解决这个问题。问题的根源在于我们想在 JS 变量释放的时候释放它所间接持有的 OC 对象，如果在垃圾回收期间我们无法进行释放，那么是不是意味着只要我们获取到 JavascriptCore 的垃圾回收开始和结束回调就能避免这个问题了呢？查找 JavascriptCore 后发现，还真的有这个回调状态，只不过接口并没有对我们开放，Heap.h 中存在一个添加观察者的接口。
图8 添加观察者
当即将进行垃圾回收和垃圾回收结束后会通知观察者：
图9 开始回调
图10 结束回调
那么现在问题来了，我们既然知道了回调方法，那么如何获得回调呢？在 OC 层面，我们可以通过 runtime 进行 hook，甚至在 C 语言层面我们也可以通过 fb 的 fishhook来实现 hook，在 C 层面我们如何 hook 一个带命名空间的函数呢？（这个问题我们并没有实现思路，如果有人知道在 iOS 中如何 hook 一个 C 函数，请及时留言指教）。
在经历了一系列尝试后，我们放弃了 hook C 函数的方法，转而寻求其他方法。回到最初的目的，实际上我们就是想保证垃圾回收之后再执行我们的JSObjectMake。因此 GCD 的延迟操作是一个很好的思路，但是到底延迟多长时间呢？这个方案似乎不是那么完美。那么还有什么操作是一个延迟释放的操作呢？__autoreleasing 应该是一个比较好的选择。
当对象前被添加 __autoreleasing 修饰时，这个对象会被延迟到自动释放池释放时才被释放。当自动释放池释放时当前runloop 一定是结束了，也就是说该垃圾回收一定是结束了（不可能一次垃圾回收分为两个 runloop ）。因此只需要将代码改为如下所图11示即可
图11 修改方案
4. 总结
这个问题还是比较难定位的，首先是很难定位到垃圾回收导致问题，其次是很难找到比较好的回调，尤其是 hook c 函数，我们做了很多次尝试都没有成功。如果有人有过在 iOS 系统中 hook C 函数的实现方案，请不吝赐教，多谢多谢！
