一、介绍
最近一直在做有关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 内存情况和流程说明
二、定位问题
为了定位问题，我们进行了很多猜想，在这里我们列举两个比较有代表性的猜想。
猜想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 伪代码
三、寻找解决方案
既然基本定位到了问题的原因，那么下一步就要找方法去解决这个问题。问题的根源在于我们想在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 修改方案
四、总结
这个问题还是比较难定位的，首先是很难定位到垃圾回收导致问题，其次是很难找到比较好的回调，尤其是hook c++函数，我们做了很多次尝试都没有成功。如果有人有过在iOS系统中hook C++函数的实现方案，请不吝赐教，多谢多谢！
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
