在「多线程回调 + SQLite + Druid 连接池」这个组合下: 并发写冲突、SQLITE_BUSY、线程阻塞

文章目录引言需求一、先回答你最关心的 3 个问题1️⃣ 会不会有并发问题？2️⃣ 会不会死锁？3️⃣ 等待时间会不会很长？二、为什么 SQLite + Druid + 多线程 = 灾难组合？1️⃣ SQLite 的锁模型（重点）2️⃣ Druid 连接池的“坑”3️⃣ 回调线程 ≠ 业务线程三、真实会发生的问题清单（你大概率会踩）四、✅ 正确架构方案（强烈推荐）✅ 方案一：**回调线程不直接写库（最重要）**架构实现方式✅ 方案二：SQLite 必须开的参数✅ 方案三：写合并（批量写）✅ 方案四（终极）：换 MySQL / PostgreSQL五、Druid 在 SQLite 下的正确姿势六、一句话总结引言在多线程回调+SQLite+Druid连接池场景下，因SQLite数据库级写锁机制，导致并发写冲突、SQLITE_BUSY、线程阻塞甚至应用假死。根本问题在于回调线程直接写库，引发线程堆积与连接耗尽。解决方案：回调线程不直接写库，通过内存队列（如LinkedBlockingQueue）将事件异步传递给单线程批量写入；启用WAL模式、合理配置busy_timeout；必要时迁移到MySQL/PostgreSQL。Druid连接池应设为小规模（1-2个）。核心原则：回调不阻塞，写操作串行化。需求在「多线程回调 + SQLite + Druid 连接池」这个组合下：并发写冲突、SQLITE_BUSY、线程阻塞、响应变慢、甚至死锁风险都是真实存在的。下面我按“会不会 → 为什么 → 多严重 → 怎么解”给你讲透。一、先回答你最关心的 3 个问题1️⃣ 会不会有并发问题？✅会SQLite 的写是：数据库级锁