从C到工业级Aether项目精讲 · 第12篇一、插件最恐怖的bug卸载插件3分钟后主程序崩溃了做插件系统的都懂插件是运行时最大的不稳定源。你永远不知道第三方开发者会在插件里写什么。也许是一个野指针也许是某个全局变量没清理也许是在析构函数里访问了已经被卸载的内存。但最恐怖的是下面这种用户卸载了一个插件。一切正常。3分钟后主程序毫无征兆地崩溃了。为什么不是立即崩溃因为插件在卸载时没清理干净——它的某个服务对象还挂在对象池里被其他插件持有引用。那个对象已经被析构了但引用还在。3分钟后另一个插件调用了这个悬空指针于是你的主进程轰然倒地。这个问题有多普遍Qt Creator、Eclipse、Visual Studio Code——所有插件化的大型软件都踩过这个坑。区别在于有的软件选择相信插件开发者你会好好写清理代码有的软件则选择用架构来兜底。Aether选择了后者。它的解法不是靠制度“请插件作者务必在析构前调用removeObject”而是靠状态机和强制生命周期来保证。哪怕插件作者什么都不做系统也不会因为卸载一个插件而崩溃。这篇就来拆这套方案的四个核心设计7状态状态机、初始化顺序编排、安全卸载三道防线、对象池联动清理。二、7状态状态机把插件当进程管先看最底层的东西——PluginSpec的State枚举enumState{Invalid,// 刚创建什么都不是Read,// JSON元数据读取完毕Resolved,// 依赖解析完成Loaded,// DLL加载成功IPlugin实例创建Initialized,// initialize() 执行完毕Running,// extensionsInitialized() 执行完毕Stopped,// aboutToShutdown() 执行完毕Deleted// 插件实例已销毁};8个状态从生到死每个状态的转换都有严格的守卫条件。看loadPlugin函数的骨架你就明白了voidPluginManagerPrivate::loadPlugin(PluginSpec*spec,PluginSpec::State destState){// 守卫只有紧邻的上一个状态才能进入下一个状态if(spec-hasError()||spec-state()!destState-1)return;switch(destState){casePluginSpec::Loaded:spec-d-loadLibrary();break;casePluginSpec::Initialized:spec-d-initializePlugin();break;casePluginSpec::Running:spec-d-initializeExtensions();break;casePluginSpec::Stopped:spec-d-stop();break;casePluginSpec::Deleted:spec-d-kill();break;default:break;}}注意这个条件spec-state() ! destState - 1。它意味着状态机不允许跳步。你不能从Resolved直接跳到Running必须先经过Loaded再经过Initialized。这个设计的精妙之处在于——任何一步失败了状态机就停在那里不会继续往前走也不会往后回退。状态直接反映了插件走到了哪一步哪里出了问题。举个例子如果某个插件的initialize()抛了异常它的状态停留在Initialized实际上报错了hasErrortrue。后续依赖它的其他插件在编排时会因为依赖状态不对而拒绝加载而不是稀里糊涂地访问一个半残的插件。状态机在这里不是花架子它是一张进度表更是一张保险单。三、初始化顺序编排先爹后儿子中间卡住就回滚插件系统的第二大难题是初始化顺序。插件A依赖插件BB依赖C。那加载顺序必须是C→B→A。但如果有人写了循环依赖呢A依赖BB依赖CC依赖AAether的解法在一个递归函数里boolPluginManagerPrivate::loadQueue(PluginSpec*spec,QListPluginSpec*queue,QListPluginSpec*circularityCheckQueue){if(queue.contains(spec))returntrue;// 循环依赖检测if(circularityCheckQueue.contains(spec)){spec-d-hasErrortrue;spec-d-errorStringCircular dependency detected:...;returnfalse;}circularityCheckQueue.append(spec);// 先处理依赖for(autodep:spec-dependencySpecs()){if(!loadQueue(dep,queue,circularityCheckQueue))returnfalse;// 依赖加载失败自己也失败}// 把自己加入队列末尾queue.append(spec);returntrue;}这是典型的拓扑排序 循环依赖检测。一个list用来做DFS遍历另一个list做排序结果。然后loadPlugins分三个阶段执行voidPluginManagerPrivate::loadPlugins(){QListPluginSpec*queueloadQueue();// 第一阶段加载DLLforeach(PluginSpec*spec,queue)loadPlugin(spec,PluginSpec::Loaded);// 第二阶段调用initialize()foreach(PluginSpec*spec,queue)loadPlugin(spec,PluginSpec::Initialized);// 第三阶段调用extensionsInitialized()// 注意这里逆序遍历Utils::reverseForeach(queue,[this](PluginSpec*spec){loadPlugin(spec,PluginSpec::Running);if(spec-state()PluginSpec::Running){delayedInitializeQueue.append(spec);}else{// 初始化失败清理spec-d-kill();}});}为什么第一、第二阶段正序第三阶段逆序因为这三个阶段解决的是不同的问题DLL加载Loaded阶段从根依赖开始加载儿子依赖爹爹先加载。initialize阶段同样从根依赖开始初始化——爹先把服务注册到对象池儿子才能从池子里拿。extensionsInitialized阶段逆序因为爹的服务已经注册好了儿子先用爹的服务轮到你爹的时候它不需要你儿子的服务。如果不逆序会怎样考虑ACorePlugin→ BHomePlugin这个依赖链。A注册IMainWindowServiceB在extensionsInitialized里拿这个服务来注册页面。如果第三阶段也正序跑先跑A的extensionsInitialized——但A已经没事可做了它的服务在initialize里就注册完了。再跑B——B拿到A的服务正常。看起来没问题换个场景ACorePlugin→ BPermissionPlugin→ CHomePlugin。正序跑第三阶段A先跑extensionsInitialized无事可做→B跑无事可做→C跑拿到A和B的服务。正常。那为什么还要逆序因为Qt Creator的实践发现在更复杂的依赖网里逆序能尽早暴露子插件的错误让更基础的插件在更高优先级上保持稳定。不管顺序怎么安排核心原则只有一个爹得先准备好儿子才能上台。四、安全卸载三道防线不让一个野指针活到下一帧回到开头那个问题插件卸载3分钟后崩溃。Aether用三道防线来解决。第一道防线卸载时先停服务再删插件PluginManagerPrivate::stopAll()调用每个插件的stop()这个函数触发aboutToShutdown()回调IPlugin::ShutdownFlagPluginSpecPrivate::stop(){if(!plugin)returnIPlugin::SynchronousShutdown;statePluginSpec::Stopped;returnplugin-aboutToShutdown();}voidPluginManagerPrivate::deleteAll(){Utils::reverseForeach(loadQueue(),[this](PluginSpec*spec){loadPlugin(spec,PluginSpec::Deleted);});}先stop再delete。所有插件先执行清理逻辑持久化状态、释放资源、通知下游等所有插件都停下来了再逐个delete。这个顺序保证了你在stop里还能安全访问其他插件而delete时已经没有插件在运行了。第二道防线异步关闭 事件循环等待有些插件需要异步关闭——比如正在写数据库的事务不能立刻中断。这时候aboutToShutdown返回AsynchronousShutdown系统怎么处理casePluginSpec::Stopped:if(spec-d-stop()IPlugin::AsynchronousShutdown){asynchronousPluginsspec;connect(spec-plugin(),IPlugin::asynchronousShutdownFinished,this,PluginManagerPrivate::asyncShutdownFinished);}break;voidPluginManagerPrivate::shutdown(){stopAll();// 如果有异步关闭的插件开启事件循环等待if(!asynchronousPlugins.isEmpty()){shutdownEventLoopnewQEventLoop;shutdownEventLoop-exec();// 等所有插件发 finished 信号}deleteAll();}系统不会强行摧毁一个还不想死的插件。它等插件自己发asynchronousShutdownFinished信号再继续后面的清理。这个等待不是spinloop空转而是事件循环——主界面不会卡死。第三道防线try/catch 兜住所有异常C的异常如果跨模块传播结果往往是灾难性的——MSVC的/EHs和/EHsc混用会导致栈不展开直接跳terminate。Aether在每个关键入口都加了try/catchtry{if(!loader.load()){hasErrortrue;errorStringloader.errorString();returnfalse;}}catch(conststd::exceptionex){hasErrortrue;errorStringQString::fromUtf8(ex.what());returnfalse;}catch(...){hasErrortrue;errorStringunknown exception during DLL load;returnfalse;}initializePlugin和initializeExtensions里也是同样的模式try{if(!plugin-initialize(err)){...}}catch(conststd::exceptionex){errorStringQString::fromUtf8(ex.what());hasErrortrue;returnfalse;}catch(...){errorStringPlugin initialization failed: unknown exception;hasErrortrue;returnfalse;}这三道防线叠加的效果是一个插件就算在DLL加载时直接segfault、在initialize里throw随机异常、在aboutToShutdown里挂起等待——主程序都不会崩。最坏情况是这个插件自己被标记为hasError其他依赖它的插件加载失败但主进程活着UI响应着日志记录着。五、对象池联动清理addObject/removeObject 的时机状态机只能保证插件本身的生存周期但插件的遗产——它注册到对象池里的服务对象——怎么清理看PluginManager的对象池操作voidPluginManagerPrivate::addObject(QObject*obj){QWriteLockerlock(m_lock);if(objnullptr){qWarning()trying to add null object;return;}if(allObjects.contains(obj)){qWarning()trying to add duplicate object;return;}allObjects.append(obj);emit q-objectAdded(obj);}voidPluginManagerPrivate::removeObject(QObject*obj){if(!allObjects.contains(obj)){qWarning()object not in list;return;}emit q-aboutToRemoveObject(obj);// ← 通知持有者QWriteLockerlock(m_lock);allObjects.removeAll(obj);}标准操作addObject加入对象池removeObject移出对象池。但问题是谁负责调用removeObjectAether的答案很直白谁add的谁remove。// 典型的插件写法boolCorePlugin::initialize(QString*errorString){m_mainWindowServicenewMainWindowService();PluginManager::addObject(m_mainWindowService);returntrue;}voidCorePlugin::extensionsInitialized(){// 使用其他插件的服务...}voidCorePlugin::aboutToShutdown(){// 清理从对象池移除再析构PluginManager::removeObject(m_mainWindowService);deletem_mainWindowService;m_mainWindowServicenullptr;}这个简单的契约能解决90%的问题。但剩下的10%是什么就是插件开发者忘了写removeObject的情况。这时候系统怎么兜底shutdown的最后一关voidPluginManagerPrivate::shutdown(){stopAll();// 防线一先停服务// 等待异步插件...deleteAll();// 防线二删插件实例// 防线三检查对象池遗留if(!allObjects.isEmpty()){qDebug()There areallObjects.size()objects left in the pool.;for(QObject*obj:allObjects)qDebug() pool entry:static_castvoid*(obj);}}虽然它不能自动清理你没办法安全地delete一个不知道类型的对象但它至少能告诉你谁留下了垃圾留下了多少。完整的时序图时间线 CorePlugin PluginManager HomePlugin │ │ │ │ │ │ initialize() │ │ │ │ addObject(svc) ────────► │ │ │ │ │ objectAdded(signal) │ │ │ │ (存放于 allObjects) │ │ │ │ │ │ │ │ extensionsInitialized() │ │ │ ◄──────────────────── │ │ │ │ getObjectIMainWindowService() │ │ │ ──── 返回 svc ──────► │ │ │ │ │ │ │ │ │ │ │ 应用关闭 ... │ │ │ │ │ │ │ │ aboutToShutdown() │ │ │ │ removeObject(svc) ────► │ │ │ │ │ aboutToRemoveObject(signal) │ │ │ (从 allObjects 移除) │ │ │ delete svc │ │ │ │ │ │ │ │ ~CorePlugin() │ │ │ │ │ │遗留检查放在最后的意义如果一个插件忘了清理对象池你不会在深夜收到线上主程序挂了的告警——你只会看到一行警告日志告诉你某个插件没尽到义务。系统仍能安全退出。六、这套方案好在哪回头看整个设计你会发现它没有用任何高深的技术。没有沙箱进程隔离没有IPC通信没有信号量栅栏。它就是靠状态约定 强制顺序 兜底清理这三板斧把插件系统的稳定性提到了一个新的台阶。具体来说问题解法效果插件加载到一半挂了状态机停留 hasError标记依赖方无法继续不会访问残血插件循环依赖递归DFS检测启动时直接报错不进入加载流程初始化顺序乱拓扑排序 三阶段加载保证爹先于儿子初始化卸载不干净先stop再delete异步等待给插件充分的清理机会异常跨模块传播try/catch包围所有回调异常转成错误状态不崩进程对象池遗留shutdown最后检查可追溯可排查没有什么魔法——就是把插件当成一个有独立生命周期的进程来管理只是这个进程跑在主进程的地址空间里。彩蛋环节看到这里细心的读者可能注意到了对象池用了QReadWriteLockgetObject用QReadLockeraddObject/removeObject用QWriteLocker。为什么要读写锁而不是互斥锁答案是对象池的典型访问模式是读多写少。插件运行期间大部分时间都是在用getObject查服务只有启动和关闭时才写。读写锁在这种场景下性能比QMutex好一个数量级。那是不是所有插件操作都是线程安全的不是。状态机本身的转换不是线程安全的——它假设所有状态变迁发生在主线程。如果有人从工作线程直接调PluginManager::addObject而你恰好又在主线程遍历对象池race condition就来了。这个问题怎么解决下一篇会拆Aether的工作线程模型和跨线程调用插件的安全姿势。当然如果你等不及翻翻pluginmanager.cpp里那些被注释掉的QMutexLocker和profilingReport——那些是Qt Creator早期版本的遗迹它们走过的弯路就是最好的学习材料。 评论区聊聊你的插件项目遇到过卸载后崩溃的问题吗是怎么排查和解决的欢迎分享你的血泪史。 觉得有用点个在看让更多人看到也转发给团队里正在做插件化架构的同事——这篇能帮他少踩几个坑。这篇的核心源码在common/core/extensionsystem/下3个头文件3个cpp总共不到1500行。挖得下去的读者可以直接去看代码写得相当干净。下一篇预告工作线程 vs 主线程——插件跨线程通信的血泪史。