TranslationPlugin项目中的线程死锁问题分析与解决方案

问题背景

在YiiGuxing开发的TranslationPlugin翻译插件项目中，出现了一个潜在的线程死锁问题。该问题发生在IntelliJ IDEA插件环境中，涉及到了IDE平台的核心线程模型与插件自身线程调用的交互问题。

问题现象

当插件尝试在"read-action"（读取操作）中调用invokeAndWait方法时，IntelliJ平台抛出了IllegalStateException异常，提示"Calling invokeAndWait from read-action leads to possible deadlock"（在读取操作中调用invokeAndWait可能导致死锁）。

技术分析

IntelliJ平台线程模型

IntelliJ平台采用了一种特殊的线程模型来保证UI响应性和数据一致性：

1. EDT（事件分发线程）：负责所有UI更新操作
2. Read Action：允许并发执行的只读操作
3. Write Action：独占式的写入操作

问题根源

异常堆栈显示，插件在以下场景中触发了问题：

1. 插件启动了一个非阻塞的读取操作（NonBlockingReadAction）
2. 在读取操作完成后的回调中，尝试通过invokeAndWait同步执行UI更新
3. 此时如果读取操作被取消（cancel），就会触发这个异常

死锁风险

这种调用模式存在死锁风险的原因是：

• invokeAndWait会阻塞当前线程等待EDT执行完成
• 如果EDT正在等待读取锁释放，而读取操作又在等待invokeAndWait完成
• 这就形成了经典的死锁条件：两个线程互相等待对方持有的资源

解决方案

最佳实践

1. 避免在读取操作中同步调用UI更新：

   • 使用invokeLater替代invokeAndWait
   • 或者将UI更新操作与读取操作分离

2. 正确处理异步操作的生命周期：

   • 在操作被取消时，应清理资源并避免继续执行回调

3. 使用平台提供的安全API：

   • 利用ProgressIndicatorUtils.runInReadActionWithWriteActionPriority
   • 使用NonBlockingReadAction的正确模式

代码改进方向

在插件代码中，应对PromisesKt.onUiThread的实现进行修改：

• 检查当前线程和操作状态
• 在读取操作上下文中自动切换为异步模式
• 添加适当的取消处理逻辑

经验总结

开发IntelliJ平台插件时，需要特别注意：

1. 理解并遵守平台的线程模型约束
2. 避免在可能被取消的操作中使用阻塞调用
3. 对异步操作进行完善的错误处理和资源清理
4. 在UI更新和后台操作之间建立清晰的边界

这个问题的修复不仅解决了当前的异常，更重要的是建立了更健壮的线程交互模式，为插件的长期稳定性打下了基础。