## 先回答你的问题

之前你看到的只是"方案摘要"，**完整文档尚未写入磁盘**。本次计划 = 全量问题清单（下面就是全部发现，不再省略）+ 落盘动作。

## 全量问题清单（3 轮全仓扫描 + 源码核实，共 7 高 + 12 中 + 12 低）

### P0 高危（并发必现：串数据/丢数据/崩溃）

1. **CleanCache 全局静态集合，跨案件串库** — `CleanCache.java:17-49`：`PERSON_LIB_NOS`/`PERSON_LIST`/`PERSON_LIST_A`/`PERSON_LIB_NO_MAP` 是不分案件的静态 HashSet/HashMultimap；清洗线程无锁 add（`:43-45`、`:22-28`），flush 线程无锁迭代+clear（`PersonLibNoService.java:17-35`、`CleanCache.getPersonList():30-41`）；`DmService.java:599` 全局 clear。后果：A 清洗完成把 B 案件累积的人员冲进 A 库、B 的数据反被清空；CME。
2. **清洗完成回调删全局 TMP 目录** — `DmService.java:636-637`：`FileUtil.del(PathConst.TMP_PATH)` 整树删除+重建，其他用户在途上传/解析临时文件蒸发。
3. **GlobalCache 静态 HashMap 运行期 clear+重建无同步** — `GlobalCache.java:64-127`；触发点 `DmService.java:596`、`TableInfoService.java:67/89`、`SystemService.java:185-191`；读方遍布清洗/治理/AI 链路。后果：CME、半空缓存、模板匹配错乱。
4. **`/chat/stream` 无会话级互斥** — `AgentChatServiceImpl.java:288-307`：同一会话双标签页/双击并发双流，交错写同一 Agent 记忆槽与工作区文件（研判链路 `InsightServiceImpl.java:136,307-333` 有双保险，chat 漏了）。
5. **治理任务无防重入 + 阶段异常被吞** — `GovernController.java:55-65` 直接 execAsync 无状态检查；`GovernService.java:110` truncate 共享表、`:151-153` 全清 GOVERN_CONFIG、`:360-367` awaitStage 吞异常后后续阶段照常执行。后果：并发两条流水线互删数据、半治理落库。
6. **AiSmartCleanService.reviewItems 同步容器被击穿** — `AiSmartCleanService.java:116` 先 put 裸 ArrayList，`:450` computeIfAbsent 的 synchronizedList 工厂永不生效，判定阶段多虚拟线程并发 add、`:457` 并发序列化。后果：丢元素/AIOOBE/CME。
7. **CaseDataCache 三套互不互斥的锁** — `CaseDataCache.java:68-77` initCache 用 synchronized(bucket)，`:84-93` initPersonLibNoCache 无锁 put，`:135-146,167-170` 读无锁，`:178` findPersonVal 用读锁。后果：开案初始化期间并发读 multimap → CME/脏读。

### P1 中危（特定场景出错或性能塌陷）

8. **message_count 读改写遗留** — `AgentChatServiceImpl.java:510,529-535` persistAssistantMessage 未走 setSql 原子自增（同文件 3 处已改）；另 `sendMessage:217-227`、`deleteMessage:257-264`、`togglePin:170-177`、`toggleStar:273-283` 同型。后果：计数漂移、状态回跳。
9. **GlobalPool 全局 16 线程池被长任务占满** — `GlobalPool.java:19,35-47`：所有用户治理任务（单阶段 30-40 分钟）挤同一池，队列 10 万深导致过载表现为无限排队。
10. **@Scheduled 单线程调度器 + 回收与后台任务无互斥** — `SseService.java:133` 心跳、`CaseDataSourceReaper.java:34`、`AiCleanWatchdog.java:76`、`ChatAttachmentService.java:384` 同一调度线程；reaper/登出关闭案件数据源时，用户 40 分钟后台任务中途夭折。
11. **AgentService.agentPool 无上限无淘汰** — `AgentService.java:96,146-165`：四维 key 只增不减（仅删专家时 evict），长期运行内存泄漏；computeIfAbsent 内做 DB 查询。
12. **SystemConfManager 无锁读写 + 并发写文件互相覆盖** — `SystemConfManager.java:18,41-51`。
13. **AttachmentDocIndexer 局部 Semaphore** — `AttachmentDocIndexer.java:80`：闸门只限单附件，多用户同时上传时打向嵌入模型无全局上限（正确范式见 `FileRecognitionService.java:99-126`）。
14. **doClean 先启后台清洗后删旧数据** — `DmService.java:673-679`：新清洗写库与删旧数据并发交错。
15. **PythonExecutor 快照指纹 check-then-act** — `PythonExecutor.java:235-259` 无锁读改写 meta；`DuckdbSnapshot.java:100-109` Windows 占用时回退原库路径，子进程打不开被 Java 写锁持有的库。
16. **chat/insight 接口缺案件归属校验** — `AgentChatServiceImpl.requireSession:494-500`、`InsightServiceImpl.requireSession:531-540` 只查存在性，凭 ID 可读写他人案件会话（与 `CaseInfoService.assertOwner:260-265` 口径不一致）。
17. **GOVERN_CONFIG 全表 clear 误伤** — `GovernService.java:153`、`SystemService.java:190`：key 已含案件 ID 却全表清空。
18. **LicenseUtil static synchronized 全局锁内起 OS 子进程** — `LicenseUtil.java:44`。
19. **deletedFiles 多步删除无事务** — `DmService.java:860-907`：删 file_info 后并发删业务表+Lucene，任一步失败留孤儿。

### P2 低危（记录在案，低频/影响小）

20. SseService.closeSee 与重连竞态可踢掉新连接 — `SseService.java:119-128` vs `:54-58`。
21. InsightServiceImpl.sessionLocks 常驻泄漏 + 删会话时移除在用锁 — `:136,238,328-333`。
22. evictAgentPool 后在途流继续用旧专家配置 — `AgentService.java:373-384`。
23. PythonExecutor.evictOldExecs LRU 与并发执行互删产物 — `:313-325`。
24. UsageStore 超限并发多删事件 — `UsageStore.java:43-48`。
25. createSession 数量上限 check-then-act — `InsightServiceImpl.java:172-176`。
26. 全员共用 RUNTIME_USER_ID="default" — `AgentChatServiceImpl.java:65,332`（架构性隐患）。
27. TowerUtils.init FLAG 未用 CAS — `TowerUtils.java:29,50-73`。
28. DuckdbUnpooledDataSource.setNetworkTimeout 每连接新建 executor 不关闭（当前死代码级）— `:143-144`。
29. McpCaseSession.sessionCases 无淘汰 — `:57`。

### 附录：已排查为安全（文档中也会列出，避免重复排查）

CaseContextHolder（ScopedValue）上下文传播、附件 CAS 绑定与孤儿清理（最近已修）、研判流会话锁+DB 状态位、CaseDataSourceRegistry、DuckdbSnapshot 原子替换、SSE 用户级连接管理、Python 沙箱独立目录、雪花 ID 文件名、全部懒加载 DCL、Json OBJECT_MAPPER、CleanFactory 每请求新建 cleaner。

## 执行步骤

1. **补查 3 个盲区**（前几轮未深入，写入文档前先确认）：Redis key 是否含用户/案件标识、Lucene IndexWriter 并发用法、@Transactional 方法内外部 IO。只做精准 grep + 读关键文件。
2. **写入完整文档** `docs/design/concurrency-issues-and-fixes.md`：上述全部 29 项逐条展开【位置｜现状代码｜多用户触发场景｜后果｜修复方案含代码要点（复用项目既有范式）】+ 附录安全清单 + 修复路线图（P0 全部 → P1 按 8/10/14 优先）+ 并发回归验证建议。
3. 回复中给出文档链接与 TL;DR。