Inicio Explorar Ayuda
Registro Iniciar sesión
vectorSeek
/
zsjz-ai
5
0
Fork 0
Archivos Incidencias 0 Pull Requests 0 Wiki
Árbol: da3d559ebc
Ramas Etiquetas
zsjz-ai
/
.zcode
/
plans
/
plan-sess_5e17c54e-213e-4bc5-94ea-ec2a4664eb1b.md

plan-sess_5e17c54e-213e-4bc5-94ea-ec2a4664eb1b.md 6.7 KB
Histórico Raw

先回答你的问题

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

全量问题清单（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 中危（特定场景出错或性能塌陷）

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

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

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