master

cann-robot优化多线程访问下化context可能存在竞争导致的数据错误问题

2c99f5fb创建于 5 天前历史提交

文件	最后提交记录	最后更新时间
mc2_aclnn_util.cpp	整改mc2部分仓内重名头文件现象 Co-authored-by: chenyifan<chenyifan66@h-partners.com> # message auto-generated for no-merge-commit merge: !5637 merge clear_repeat_h into master 整改mc2部分仓内重名头文件现象 Created-by: mutex_lock Commit-by: chenyifan Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> - 整改mc2部分仓内重名头文件现象 --- | 文件名 | 源码路径|处理方式 | |-----|-----|-----| | all_gather_formulaic_tiling.h | mc2/all_gather_matmul/op_host/op_tiling/all_gather_formulaic_tiling.h,mc2/all_gather_matmul_v2/op_host/op_tiling/all_gather_formulaic_tiling.h | 都为内部头文件，但内容不同，已修改all_gather_matmul_v2算子内文件的命名 | | grouped_matmul_host_util.h | gmm/grouped_matmul/op_host/grouped_matmul_host_util.h,mc2/3rd/grouped_matmul/op_tiling/grouped_matmul_host_util.h | 都为内部头文件，但内容不完全相同，已修改mc2/3rd内文件的命名 | | grouped_matmul_tiling.h | gmm/grouped_matmul/op_host/op_tiling/grouped_matmul_tiling.h,mc2/3rd/grouped_matmul/op_tiling/grouped_matmul_tiling.h | 都为内部头文件，但内容不完全相同，已修改mc2/3rd内文件的命名 | | matmul_util.h | mc2/3rd/common/op_host/op_api/matmul_util.h,mc2/common/utils/matmul_util.h | 都为内部头文件，但内容不完全相同，已修改mc2/3rd内文件的命名，并消除宏冲突 | | runtime_kb_api.h | common/stub/op_tiling/runtime_kb_api.h,mc2/3rd/ops_legacy/op_tiling/runtime_kb_api.h | 声明完全相同，但实现侧不同，删除mc2/3rd/ops_legacy下的runtime_kb_api.h | | tiling_type.h | common/include/op_host/tiling_type.h,mc2/3rd/common/op_host/op_tiling/tiling_type.h |都为内部文件，但内容不完全相同，保留common/include/op_host/tiling_type.h统一使用 | | tuning_tiling_reflection_utils.h | common/stub/op_tiling/register/tuning_tiling_reflection_utils.h,mc2/3rd/ops_legacy/op_tiling/register/tuning_tiling_reflection_utils.h | 声明完全相同，删除mc2/3rd/ops_legacy/op_tiling/register/tuning_tiling_reflection_utils.h | | tuning_tiling_registry.h | common/stub/op_tiling/register/tuning_tiling_registry.h,mc2/3rd/ops_legacy/op_tiling/register/tuning_tiling_registry.h | 声明完全相同，删除mc2/3rd/ops_legacy/op_tiling/register/tuning_tiling_registry.h | --- ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> https://gitcode.com/cann/ops-transformer/issues/2550 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> rdv ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [x] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!5637	12 天前
mc2_aclnn_util.h	【A2】mc2算子添加非连续性校验 Co-authored-by: lyt_claire<luyitong1@huawei.com> # message auto-generated for no-merge-commit merge: !3676 merge mc2ContiguousFix into master 【A2】mc2算子添加非连续性校验 Created-by: lyt_claire Commit-by: lyt_claire Merged-by: cann-robot Description: ## 描述 all_gather_matmul、all_gather_matmul_v2、 matmul_all_reduce、matmul_reduce_scatter、 matmul_reduce_scatter_v2添加非连续性校验 修复内容： 1.mc2/matmul_all_reduce/op_api/aclnn_weight_quant_matmul_all_reduce.cpp文件中antiquantOffset的空指针校验 优化内容： 1.mc2/matmul_all_reduce/op_api/matmul_all_reduce_util.cpp文件中对于空tensor的放行，对于matmul all reduce来说，空tensor（m、k、n任意一轴为0）输入合法，直接跳过。 2.对MatmulReduceScatter、MatmulAllReduce算子的所有非连续校验从空指针校验后挪至输入shape的校验之后，不影响原先aclnn接口的校验顺序。 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [x] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!3676	1 个月前
mc2_context.cpp	优化多线程访问下化context可能存在竞争导致的数据错误问题 Co-authored-by: zzg_code<zengzhiguo1@huawei.com> # message auto-generated for no-merge-commit merge: !5851 merge updatacontext into master 优化多线程访问下化context可能存在竞争导致的数据错误问题 Created-by: zzg_code Commit-by: zzg_code Merged-by: cann-robot Description: ## 描述 cm2 context在设计之初只考虑了dispatch 和combine算子，因此在代码中定义了静态对象，但是目前随着发展context需要被多个的mc2算子引用，这种情况下静态成员可能导致在多线程情况下的数据竞争问题，因此修改设计逻辑 ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/2648 ## 测试 # MC2 Context 代码检视报告 **检视日期**: 2026-05-25 **检视文件**: 5851.diff **变更模块**: mc2/common/op_api, mc2/moe_distribute_* --- ## 1. 总体概述 本次代码变更主要涉及 MC2 通信上下文管理模块的重构，核心变更包括： 1. **架构调整**：移除单例模式，改为每次调用时创建实例（解决多线程数据冲突问题） 2. **缓存机制重构**：将"获取或创建"合并逻辑拆分为"检查缓存"和"创建"两步 3. **接口调整**：修改方法签名和参数顺序 4. **日志优化**：提升关键日志级别从 DEBUG 到 INFO，修正格式化字符串类型 5. **版本兼容性调整**：降低 HCCL_CHANNEL_SUPPORT_VERSION 版本号 变更范围涉及 3 个文件，约 100+ 行代码修改。 --- ## 2. 代码变更清单 | 文件 | 变更类型 | 变更内容 | |------|---------|---------| | mc2_context.h | 接口修改 | 删除 GetInstance() 静态方法声明；修改 CreatMc2Context 参数顺序；删除 GetOrCreateMc2Context；新增 CheckContextCache；修改版本宏定义 | | mc2_context.cpp | 实现修改 | 删除单例实现；重构 GetMc2ContextTensor 逻辑；日志级别提升；格式化字符串修复；缓存检查逻辑拆分 | | moe_distribute_combine_v2_base.cpp | 调用方修改 | 修改 opName 从 "moe_distribute_dispatch_combine_v2" 到 "moe_distribute_v2" | | moe_distribute_dispatch_v2_base.cpp | 调用方修改 | 修改 opName 从 "moe_distribute_dispatch_combine_v2" 到 "moe_distribute_v2" | --- ## 3. 检视问题列表 ### 🔴 严重问题 无 ### 🟡 中等问题 #### P1-1: 方法签名参数顺序调整可能破坏调用方 **问题描述**： CreatMc2Context 方法的参数顺序从 (hcclHandle, mc2ContextTag, engine, protocol, ctx, mc2ContextStruct) 改为 (hcclHandle, mc2ContextTag, engine, protocol, mc2ContextStruct, ctx, hcclBuffSize)，参数顺序和位置调整可能影响代码可读性和调用方兼容性。 **代码位置**： ```cpp // mc2_context.h:58-59 - aclnnStatus CreatMc2Context(const HcclComm &hcclHandle, const std::string &mc2ContextTag, - const CommEngine &engine, const CommProtocol &protocol, void *&ctx, Mc2MoeContext *mc2ContextStruct); + aclnnStatus CreatMc2Context(const HcclComm &hcclHandle, const std::string &mc2ContextTag, + const CommEngine &engine, const CommProtocol &protocol, + Mc2MoeContext *mc2ContextStruct, void *&ctx, uint64_t &hcclBuffSize); ``` **修改建议**： 1. 参数顺序应遵循：输入参数 -> 输入输出参数 -> 输出参数 2. 当前调整后 mc2ContextStruct（输入）在前，ctx（输出）在后，符合规范 ✅ 3. 建议在函数注释中明确标注每个参数的方向 **状态**: 已符合规范，无需修改 --- #### P1-2: 版本号降低可能导致不兼容 **问题描述**： HCCL_CHANNEL_SUPPORT_VERSION 从 90000000 降低到 89999700，可能导致在版本号在 [89999700, 90000000) 范围内的环境上，功能从"不启用"变为"启用"，引入不稳定风险。 **代码位置**： ```cpp // mc2_context.h:21 - #define HCCL_CHANNEL_SUPPORT_VERSION 90000000 + #define HCCL_CHANNEL_SUPPORT_VERSION 89999700 ``` **修改建议**： 1. 确认降低版本号的原因（是否为了兼容旧版本 HCCL？） 2. 在代码注释中说明版本号的含义和选择依据 3. 建议在 CHANGELOG 中记录此兼容性变更 **状态**: 待确认版本兼容范围 --- #### P1-3: 日志级别提升可能影响生产环境性能 **问题描述**： 多处日志从 OP_LOGD（DEBUG）提升到 OP_LOGI（INFO），在高频调用场景下可能导致生产环境日志量激增。 **代码位置**： ```cpp // mc2_context.cpp 多处，示例： - OP_LOGD("Start to get HCCL communication handle, groupEp: %s", groupEp); + OP_LOGI("Start to get HCCL communication handle, groupEp: %s", groupEp); ``` **修改建议**： 1. 评估这些日志的打印频率（每秒多少次） 2. 高频日志建议保持 DEBUG 级别 3. 或添加调用频率限制机制（如每 N 次打印一次） **状态**: 需评估高频场景影响 --- #### P1-4: 错误处理路径可优化 **问题描述**： CheckContextCache 方法中，当缓存查找失败（hcclRet != HCCL_SUCCESS）时，仅设置 hcclBuffSize = 0 并返回成功，但未清理可能的残留状态。 **代码位置**： ```cpp // mc2_context.cpp:481-484 if (hcclRet != HCCL_SUCCESS) { // 没找到缓存，创建context hcclBuffSize = 0; OP_LOGI("Context cache not found, need to create"); return ACLNN_SUCCESS; } ``` **修改建议**： 1. 确认 ctx 参数在此场景下是否需要显式设置为 nullptr 2. 添加注释说明"缓存不存在是正常流程，非错误情况" **状态**: 建议优化 --- ### 🔵 建议优化 #### P2-1: 重复代码可抽取 **问题描述**： moe_distribute_combine_v2_base.cpp 和 moe_distribute_dispatch_v2_base.cpp 中的 opName 定义完全相同，可抽取为公共常量。 **代码位置**： ```cpp // 两个文件中相同代码 const char *opName = "moe_distribute_v2"; ``` **修改建议**： ```cpp // 建议在头文件中定义 namespace Mc2Aclnn { constexpr const char* MOE_DISTRIBUTE_V2_OP_NAME = "moe_distribute_v2"; } ``` --- #### P2-2: 注释风格不一致 **问题描述**： 新增注释使用中文，但其他代码注释为英文或无注释，风格不统一。 **代码位置**： ```cpp // mc2_context.cpp:481 if (hcclRet != HCCL_SUCCESS) { // 没找到缓存，创建context ``` **修改建议**： 统一使用英文注释： ```cpp if (hcclRet != HCCL_SUCCESS) { // Cache not found, need to create context ``` --- #### P2-3: 魔法数字需注释 **问题描述**： hcclBuffSize = 0; 作为特殊状态标记，建议使用常量或添加注释。 **代码位置**： ```cpp // mc2_context.cpp:497 hcclBuffSize = 0; // 先默认为0，后续根据缓存情况赋值 ``` **修改建议**： ```cpp constexpr uint64_t HCCL_BUFF_SIZE_NOT_INITIALIZED = 0; hcclBuffSize = HCCL_BUFF_SIZE_NOT_INITIALIZED; ``` --- ## 4. 优点总结 ✅ **日志格式修复**：将 %d 改为 %u 匹配 uint32_t 类型，避免未定义行为 ✅ **代码职责分离**：将 GetOrCreateMc2Context 拆分为 CheckContextCache 和 CreatMc2Context，职责更清晰 ✅ **输出参数规范化**：CreatMc2Context 的 hcclBuffSize 从成员变量改为输出参数，减少隐式状态依赖 ✅ **缓存流程优化**：明确区分"命中缓存"和"需要创建"两种路径，便于问题定位 ✅ **日志可观测性提升**：关键路径日志提升到 INFO 级别，便于生产环境监控 ✅ **多线程安全**：移除单例模式，改为临时变量，解决多线程数据冲突问题 --- ## 5. 风险评估 | 风险项 | 风险等级 | 影响范围 | 状态 | |--------|---------|---------|------| | 单例移除导致状态丢失 | ~~🔴 高~~ | 功能正确性 | ✅ 已澄清 - 多线程安全设计 | | 缓存键名变更导致不兼容 | ~~🔴 高~~ | 生产环境缓存 | ✅ 已澄清 - 首次创建无兼容问题 | | 版本号降低导致功能变更 | 🟡 中 | 版本兼容性 | 待确认版本依赖范围 | | 日志级别提升影响性能 | 🟡 中 | 生产环境性能 | 需评估日志频率 | | 方法签名变更影响调用方 | 🟢 低 | 编译兼容性 | ✅ 已同步修改所有调用方 | --- ## 6. 代码质量评分 **总分**: 85/100 | 维度 | 得分 | 说明 | |------|------|------| | 架构设计 | 90 | 单例移除解决多线程问题，职责分离清晰 | | 代码规范 | 85 | 格式化字符串修复正确，注释风格可统一 | | 错误处理 | 80 | CheckContextCache 路径可优化 | | 可维护性 | 85 | 重复代码可抽取，魔法数字可常量化 | | 安全性 | 90 | 多线程安全，无明显安全风险 | --- ## 7. 建议与总结 ### 必须处理 无严重问题需处理 ### 建议处理 1. 统一注释风格（中文→英文） 2. 评估 INFO 日志在高频场景的性能影响 3. 确认版本号降低的兼容性范围 ### 可选优化 1. 抽取重复的 opName 为公共常量 2. 使用常量替代魔法数字 0 --- **检视结论**: 代码变更整体质量良好，架构设计合理（多线程安全优化），可合并。建议处理中等问题后合入主分支。 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!5851	5 天前
mc2_context.h	优化多线程访问下化context可能存在竞争导致的数据错误问题 Co-authored-by: zzg_code<zengzhiguo1@huawei.com> # message auto-generated for no-merge-commit merge: !5851 merge updatacontext into master 优化多线程访问下化context可能存在竞争导致的数据错误问题 Created-by: zzg_code Commit-by: zzg_code Merged-by: cann-robot Description: ## 描述 cm2 context在设计之初只考虑了dispatch 和combine算子，因此在代码中定义了静态对象，但是目前随着发展context需要被多个的mc2算子引用，这种情况下静态成员可能导致在多线程情况下的数据竞争问题，因此修改设计逻辑 ## 关联的Issue https://gitcode.com/cann/ops-transformer/issues/2648 ## 测试 # MC2 Context 代码检视报告 **检视日期**: 2026-05-25 **检视文件**: 5851.diff **变更模块**: mc2/common/op_api, mc2/moe_distribute_* --- ## 1. 总体概述 本次代码变更主要涉及 MC2 通信上下文管理模块的重构，核心变更包括： 1. **架构调整**：移除单例模式，改为每次调用时创建实例（解决多线程数据冲突问题） 2. **缓存机制重构**：将"获取或创建"合并逻辑拆分为"检查缓存"和"创建"两步 3. **接口调整**：修改方法签名和参数顺序 4. **日志优化**：提升关键日志级别从 DEBUG 到 INFO，修正格式化字符串类型 5. **版本兼容性调整**：降低 HCCL_CHANNEL_SUPPORT_VERSION 版本号 变更范围涉及 3 个文件，约 100+ 行代码修改。 --- ## 2. 代码变更清单 | 文件 | 变更类型 | 变更内容 | |------|---------|---------| | mc2_context.h | 接口修改 | 删除 GetInstance() 静态方法声明；修改 CreatMc2Context 参数顺序；删除 GetOrCreateMc2Context；新增 CheckContextCache；修改版本宏定义 | | mc2_context.cpp | 实现修改 | 删除单例实现；重构 GetMc2ContextTensor 逻辑；日志级别提升；格式化字符串修复；缓存检查逻辑拆分 | | moe_distribute_combine_v2_base.cpp | 调用方修改 | 修改 opName 从 "moe_distribute_dispatch_combine_v2" 到 "moe_distribute_v2" | | moe_distribute_dispatch_v2_base.cpp | 调用方修改 | 修改 opName 从 "moe_distribute_dispatch_combine_v2" 到 "moe_distribute_v2" | --- ## 3. 检视问题列表 ### 🔴 严重问题 无 ### 🟡 中等问题 #### P1-1: 方法签名参数顺序调整可能破坏调用方 **问题描述**： CreatMc2Context 方法的参数顺序从 (hcclHandle, mc2ContextTag, engine, protocol, ctx, mc2ContextStruct) 改为 (hcclHandle, mc2ContextTag, engine, protocol, mc2ContextStruct, ctx, hcclBuffSize)，参数顺序和位置调整可能影响代码可读性和调用方兼容性。 **代码位置**： ```cpp // mc2_context.h:58-59 - aclnnStatus CreatMc2Context(const HcclComm &hcclHandle, const std::string &mc2ContextTag, - const CommEngine &engine, const CommProtocol &protocol, void *&ctx, Mc2MoeContext *mc2ContextStruct); + aclnnStatus CreatMc2Context(const HcclComm &hcclHandle, const std::string &mc2ContextTag, + const CommEngine &engine, const CommProtocol &protocol, + Mc2MoeContext *mc2ContextStruct, void *&ctx, uint64_t &hcclBuffSize); ``` **修改建议**： 1. 参数顺序应遵循：输入参数 -> 输入输出参数 -> 输出参数 2. 当前调整后 mc2ContextStruct（输入）在前，ctx（输出）在后，符合规范 ✅ 3. 建议在函数注释中明确标注每个参数的方向 **状态**: 已符合规范，无需修改 --- #### P1-2: 版本号降低可能导致不兼容 **问题描述**： HCCL_CHANNEL_SUPPORT_VERSION 从 90000000 降低到 89999700，可能导致在版本号在 [89999700, 90000000) 范围内的环境上，功能从"不启用"变为"启用"，引入不稳定风险。 **代码位置**： ```cpp // mc2_context.h:21 - #define HCCL_CHANNEL_SUPPORT_VERSION 90000000 + #define HCCL_CHANNEL_SUPPORT_VERSION 89999700 ``` **修改建议**： 1. 确认降低版本号的原因（是否为了兼容旧版本 HCCL？） 2. 在代码注释中说明版本号的含义和选择依据 3. 建议在 CHANGELOG 中记录此兼容性变更 **状态**: 待确认版本兼容范围 --- #### P1-3: 日志级别提升可能影响生产环境性能 **问题描述**： 多处日志从 OP_LOGD（DEBUG）提升到 OP_LOGI（INFO），在高频调用场景下可能导致生产环境日志量激增。 **代码位置**： ```cpp // mc2_context.cpp 多处，示例： - OP_LOGD("Start to get HCCL communication handle, groupEp: %s", groupEp); + OP_LOGI("Start to get HCCL communication handle, groupEp: %s", groupEp); ``` **修改建议**： 1. 评估这些日志的打印频率（每秒多少次） 2. 高频日志建议保持 DEBUG 级别 3. 或添加调用频率限制机制（如每 N 次打印一次） **状态**: 需评估高频场景影响 --- #### P1-4: 错误处理路径可优化 **问题描述**： CheckContextCache 方法中，当缓存查找失败（hcclRet != HCCL_SUCCESS）时，仅设置 hcclBuffSize = 0 并返回成功，但未清理可能的残留状态。 **代码位置**： ```cpp // mc2_context.cpp:481-484 if (hcclRet != HCCL_SUCCESS) { // 没找到缓存，创建context hcclBuffSize = 0; OP_LOGI("Context cache not found, need to create"); return ACLNN_SUCCESS; } ``` **修改建议**： 1. 确认 ctx 参数在此场景下是否需要显式设置为 nullptr 2. 添加注释说明"缓存不存在是正常流程，非错误情况" **状态**: 建议优化 --- ### 🔵 建议优化 #### P2-1: 重复代码可抽取 **问题描述**： moe_distribute_combine_v2_base.cpp 和 moe_distribute_dispatch_v2_base.cpp 中的 opName 定义完全相同，可抽取为公共常量。 **代码位置**： ```cpp // 两个文件中相同代码 const char *opName = "moe_distribute_v2"; ``` **修改建议**： ```cpp // 建议在头文件中定义 namespace Mc2Aclnn { constexpr const char* MOE_DISTRIBUTE_V2_OP_NAME = "moe_distribute_v2"; } ``` --- #### P2-2: 注释风格不一致 **问题描述**： 新增注释使用中文，但其他代码注释为英文或无注释，风格不统一。 **代码位置**： ```cpp // mc2_context.cpp:481 if (hcclRet != HCCL_SUCCESS) { // 没找到缓存，创建context ``` **修改建议**： 统一使用英文注释： ```cpp if (hcclRet != HCCL_SUCCESS) { // Cache not found, need to create context ``` --- #### P2-3: 魔法数字需注释 **问题描述**： hcclBuffSize = 0; 作为特殊状态标记，建议使用常量或添加注释。 **代码位置**： ```cpp // mc2_context.cpp:497 hcclBuffSize = 0; // 先默认为0，后续根据缓存情况赋值 ``` **修改建议**： ```cpp constexpr uint64_t HCCL_BUFF_SIZE_NOT_INITIALIZED = 0; hcclBuffSize = HCCL_BUFF_SIZE_NOT_INITIALIZED; ``` --- ## 4. 优点总结 ✅ **日志格式修复**：将 %d 改为 %u 匹配 uint32_t 类型，避免未定义行为 ✅ **代码职责分离**：将 GetOrCreateMc2Context 拆分为 CheckContextCache 和 CreatMc2Context，职责更清晰 ✅ **输出参数规范化**：CreatMc2Context 的 hcclBuffSize 从成员变量改为输出参数，减少隐式状态依赖 ✅ **缓存流程优化**：明确区分"命中缓存"和"需要创建"两种路径，便于问题定位 ✅ **日志可观测性提升**：关键路径日志提升到 INFO 级别，便于生产环境监控 ✅ **多线程安全**：移除单例模式，改为临时变量，解决多线程数据冲突问题 --- ## 5. 风险评估 | 风险项 | 风险等级 | 影响范围 | 状态 | |--------|---------|---------|------| | 单例移除导致状态丢失 | ~~🔴 高~~ | 功能正确性 | ✅ 已澄清 - 多线程安全设计 | | 缓存键名变更导致不兼容 | ~~🔴 高~~ | 生产环境缓存 | ✅ 已澄清 - 首次创建无兼容问题 | | 版本号降低导致功能变更 | 🟡 中 | 版本兼容性 | 待确认版本依赖范围 | | 日志级别提升影响性能 | 🟡 中 | 生产环境性能 | 需评估日志频率 | | 方法签名变更影响调用方 | 🟢 低 | 编译兼容性 | ✅ 已同步修改所有调用方 | --- ## 6. 代码质量评分 **总分**: 85/100 | 维度 | 得分 | 说明 | |------|------|------| | 架构设计 | 90 | 单例移除解决多线程问题，职责分离清晰 | | 代码规范 | 85 | 格式化字符串修复正确，注释风格可统一 | | 错误处理 | 80 | CheckContextCache 路径可优化 | | 可维护性 | 85 | 重复代码可抽取，魔法数字可常量化 | | 安全性 | 90 | 多线程安全，无明显安全风险 | --- ## 7. 建议与总结 ### 必须处理 无严重问题需处理 ### 建议处理 1. 统一注释风格（中文→英文） 2. 评估 INFO 日志在高频场景的性能影响 3. 确认版本号降低的兼容性范围 ### 可选优化 1. 抽取重复的 opName 为公共常量 2. 使用常量替代魔法数字 0 --- **检视结论**: 代码变更整体质量良好，架构设计合理（多线程安全优化），可合并。建议处理中等问题后合入主分支。 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-transformer!5851	5 天前