COM引用计数兼浅谈JavaScript与ActiveX Web编程

     浅谈来讲，COM的引用计数牵扯作为参数或者作为返回值两种场景来讨论。COM接口作为参数来传递时，通常可以看到在函数调用过程中引用计数不用增减即可，因为传递参数时，caller自然地拥有一次”参数引用，在作为参数COM接口不会被释放掉。

     在函数内部使用COM接口不会存在太多问题，但是，例如保存之类的操作，则需要增加引用计数，因为无法假定外界不释放。

    在作为返回值的场景中，由于返回出去让外界去使用，则在返回后应该至少保持引用计数为一，保证外界操作时，不至于是一个“野”COM接口。

    其它场景可以类比这两个原则，到底是在Caller嵌套之内还是在Callee无嵌套之外？

 

  例如， 在JavaScript与ActiveX结合的富WEB客户端应用中，我们可以看到JavaScript与ActiveX交互存在两个方向的视角。正向来看，JavaScript可以直接使用ActiveX提供的COM接口，反向来看，而AxtiveX也可以利用EVENT的COM接口主动“通知”JavaScript(前提是JavaScript需要给此Event增加JavaScript处理代码)。JavaScript与ActiveX的正向过程可以说的，就是JavaScript的对象，会被自动封装成自动化COM对象与ActiveX的COM体系进行对接，这里也可以看到。技术的边界之间通讯，还是遵从“双协议栈”的模式，JavaScript引擎同时具有了两面，一面面向纯JavaScript，另一面面向COM体系，经过这一双协议栈则实现了通讯和对接的。在高性能JavaScript书本中介绍了，由于“双协议栈”类似桥梁，存在桥梁的过路过桥费，所以，尽可能在自己的技术边界中活动是最节省成本的。

  对于JavaScript与ActiveX反向Event过程，很多人听说Event(事件)，就很容易错误地类比到window编程中的message，或者鼠标点击事件等。其实实际上ActiveX的事件接口，只是相当于一个“回调”函数，中间很有可能没有任何windows消息的参与，就是直接函数调用而已。

   所以，如果在ActiveX中事件接口中暴露的信息是通过COM接口的形式，则其实是符合Caller嵌套之内的引用计数原则，在fire事件时，不用增加引用计数即可。

   既然存在了引用计数，在JavaScript与ActiveX通过自动化COM对象的应用中，那么这些对象何时消亡？特别是JavaScript正向调用ActiveX返回信息中是一个COM对象，根据这段的研究来看(增加打印)，JavaScript确实实现了垃圾回收，会在某个时间点，一次性地批量回收一批。