多线程读取QHash是否安全？线程操作关联QMap崩溃原因咨询

结论：存在潜在竞争风险，程序崩溃大概率与此相关 #

具体竞争场景拆解 #

1. QHash本身的线程安全限制
   Qt的QHash、QMap、QList均不属于线程安全容器：

   • 若初始化完成后，仍有线程（包括主线程）对QHash进行结构修改（添加/删除键），此时其他线程读取QHash获取对应QMap的操作，会触发竞争，破坏QHash内部哈希表结构，导致返回无效的QMap引用/指针。
   • 即使仅读取QHash，如果有其他线程同时执行hash[threadId]（operator[]在键不存在时会自动插入默认构造的QMap，属于写操作），同样会引发竞争。

2. QMap的跨线程访问风险
   如果代码逻辑存在疏漏（比如线程ID重复、错误地让多个线程访问同一个QMap），直接对非线程安全的QMap进行并发读写，会破坏其内部红黑树结构，直接触发崩溃。

崩溃的直接关联点 #

你遇到的崩溃几乎可以确定和多线程竞争有关：

• 若QHash在竞争中损坏，线程拿到的QMap是无效内存，后续对QMap的读写操作会触发段错误或内存访问异常。
• 若QMap被多线程并发操作，内部结构被破坏，会直接导致程序崩溃。

修复建议 #

• 初始化后锁定QHash结构：确保所有工作线程启动前，主线程完成QHash的所有键添加操作，后续绝对不修改QHash的结构（不增删键）。线程读取时使用hash.value(threadId)而非operator[]，避免意外插入新键。此时QHash仅被多线程只读访问，符合Qt容器的安全规则。
• 直接传递QMap指针：初始化阶段主线程为每个线程创建独立的QMap，将指针直接传递给对应线程，完全绕过QHash的跨线程访问，从根源消除QHash的竞争风险。
• 添加互斥锁保护：如果必须在运行时修改QHash结构，所有对QHash的访问（读、写）都要通过QMutex加锁，确保同一时间只有一个线程操作QHash。
• 替换为线程安全容器：使用Qt 5.10+提供的QConcurrentHash替代QHash，但注意它仅保证哈希表本身的线程安全，内部的QMap仍需确保仅被对应单线程访问。

内容的提问来源于stack exchange，提问作者TH Hu