📋 Issue 分析报告

判定结果: ✅ 确认为有效问题

问题类型: bug
分类审视: 标题模板选择正确，与问题类型一致；Issue 类型已修正为「缺陷」
严重程度: medium
置信度: 80%

📋 问题摘要

线程复用时通知容量缓存被无条件覆盖，导致需求减小时缓存减小而底层资源未释放，后续需求恢复时重复分配资源

🔍 根因分析

提供的代码文件未包含 thread_manager.cc 和 aicpu_ts_thread.cc，无法直接验证，但基于 Issue 描述的详细代码逻辑分析：在 ThreadMgr::SupplementNotify() 中，仅在目标数量大于缓存数量时增配 notify，但之后无条件执行 threadVec[i].notifyNum = config[i].notifyNumPerThread; 覆盖缓存。当需求从 8 降到 4 时，底层 AicpuTsThread::SupplementNotify() 不释放资源（实际仍为 8），但缓存被覆盖为 4。下次需求从 4 升回 8 时，缓存为 4，判断为需要增配，于是又分配 4 个，实际变为 12。如此往复导致资源持续增长。该逻辑符合常见的资源管理缺陷模式，且 Issue 提供了具体的函数名、变量名和代码片段，描述自洽且合理。

📁 涉及的文件/模块

• src/coll_communicator_mgr/resource_mgr/local/my_rank/comm_engine/threads/thread_manager.cc
• src/base_comm/resources/comm_engine_res/threads/aicpu_ts_thread.cc

💡 建议的修复方案

建议在 ThreadMgr::SupplementNotify() 中，增配成功后更新缓存为 max(原容量, 目标需求)，需求减小时保留原值。同时检查线程 handle 复用场景，确保实际资源数不超过历史最大值。具体修改位置为 thread_manager.cc 中 SupplementNotify() 函数内的缓存更新逻辑。

⚠️ 风险提示

修复时需确保在真正释放资源时才减小缓存，否则可能导致缓存与实际不符。需检查是否有其他逻辑依赖 notifyNum 的当前值，以及缩容逻辑是否会引入新的资源同步问题。

👤 责任人与责任田分配

src/coll_communicator_mgr/ → @dingweiqin_57（hcomm-mgr） - HCOMM 集合通信域管理 HCCM（拓扑、建链、rank info detect）

• src/coll_communicator_mgr/resource_mgr/local/my_rank/comm_engine/threads/thread_manager.cc

src/base_comm/ → @Innoecho（hcomm-base） - HCOMM 基础通信层（endpoint、channel、内存、线程）

• src/base_comm/resources/comm_engine_res/threads/aicpu_ts_thread.cc

待确认负责人: @dingweiqin_57 @Innoecho

⏳ 等待人工确认

请以上负责人确认此问题：

• 确认有效 → 评论 /label add confirmed 添加确认标签，并由责任人跟进处理
• 如非有效问题 → 回复说明理由（供 Issue 提出人参考），并关闭 Issue

_{本回复为 AI 结合源码深度分析生成，将同步对应责任田团队进行二次确认。}

/assign @dingweiqin_57 @Innoecho

/label add confirmed

问题已确认，将于10.23完成修改

/assign @littlemons