故障排查

请分析 Java CPU 突升与锁等待，整理可复核的线程证据。结合所提供的工程和业务证据开展检查；资料不足时先列出影响结论的关键问题，可以推进的部分标注假设。不要编造文件、日志、测量结果或已完成的操作。

适用边界：适用于已授权的Java进程。线程CPU数据具有采样窗口，栈是采样结束时的快照；thread -b只覆盖文档说明的synchronized阻塞，不能据此排除Lock等待。

输入：故障时间与业务现象、进程CPU及请求指标、线程采样输出、JDK与Arthas版本、采样间隔及资源预算。

分析 Arthas thread 输出时，核对 CPU 差值采样、自身开销、栈快照时点和阻塞识别的覆盖限制。按项目实际版本解释规则，不机械沿用旧示例。

执行步骤：
1. 先核对目标进程、故障窗口和用户可观察影响，把进程CPU、请求量、延迟、错误及近期发布放到统一时间轴；不要用一次线程截图代替持续高负载证据。
2. 选择有限的采样次数和时间窗口，记录实际间隔、线程标识和诊断耗时；需要调整间隔时说明开销与代表性取舍，不将文档示例值认定为当前业务最佳值。
3. 比较多次采样中的高CPU线程与堆栈，区分应用任务、编译或GC等内部线程以及Arthas自身线程；相同线程可能处理不同任务，不能仅按线程名推定业务归属。
4. 对低CPU而请求变慢的情况检查等待状态与锁关系，记录持有者和等待者能否对应；没有查到synchronized阻塞时，不直接宣布不存在并发锁、队列或网络等待。
5. 把热点栈关联到业务入口和具体负载，列出能够解释现象的假设及反证条件；继续观测应针对少量候选，不直接全类通配追踪或以宽泛表达式采集敏感参数。
6. 形成缓解与根因修复的分工，规定再次采样与业务指标复核条件；故障缓解后仍需比较同等负载，避免把流量下降造成的CPU下降当作代码修复有效。

输出：交付采样时间线、热点与等待线程表、锁关系、候选原因与证据强度、后续验证计划。注明采样范围、遗漏可能及诊断自身影响；只有具备运行记录的项目才填写实测数值，未验证根因不得写成确定结论。

来源核验日期：2026-09-08。
- 阿里巴巴 / Arthas《Arthas thread：线程 CPU 与阻塞观察》：https://github.com/alibaba/arthas/blob/be42fd932a26456988b97d863087b116de19253f/site/docs/doc/thread.md

验证说明：已核对上述公开来源及具体规则或能力；本模板尚未通过模型对比实验或线上业务实测，不能以来源品牌、仓库热度或扫描分数代替验收。

来源许可说明：Apache-2.0。本条为中文原创整理，来源内容与本模板补充要求已在正文区分。

请核对 Java 进程已加载类的来源，排查依赖冲突。结合所提供的工程和业务证据开展检查；资料不足时先列出影响结论的关键问题，可以推进的部分标注假设。不要编造文件、日志、测量结果或已完成的操作。

适用边界：适用于已授权的Java进程诊断。先核对JDK、Arthas版本和attach条件；本模板仅安排观察，不使用热替换或执行会改变业务对象的表达式。

输入：目标进程与启动路径证据、异常类全名与堆栈、预期制品及校验信息、JDK与Arthas版本、部署结构与类路径。

使用 Arthas sc 查看已加载类的 code-source、classLoaderHash，并按类加载器筛选；注意默认匹配会包含子类。按项目实际版本解释规则，不机械沿用旧示例。

执行步骤：
1. 先将目标PID与实际监听服务、启动命令、JAR或容器对应，记录制品版本和启动时间；无法确认进程归属时停止针对该进程的诊断，避免把另一实例当成目标。
2. 以异常中的完整类名收集sc详细信息，列出所有匹配类的名称、类加载器标识与代码来源；核对是否混入子类，不把多行输出直接判断为同一个类被重复加载。
3. 把来源路径与预期部署制品、依赖树及实际文件对应，检查是否有旧目录、重复JAR、容器挂载或共享库抢先生效；仅靠文件名相同不能确认版本相同。
4. 遇到同名类由不同加载器加载时，按加载器区分结果与调用上下文，说明证据能证明什么；hash标识用于当前运行期定位，不将其当成跨重启稳定的版本号。
5. 比较制品清单、校验值和部署记录，分别评估包未更新、启动路径错误或依赖选择变化；磁盘文件已更新不代表内存类同步变化，缺少字节码证据时保留结论边界。
6. 给出修复后的验证方案，按正确制品和正确启动入口重新确认同一业务路径；若需重启或调整依赖，应在独立变更中执行，保存旧证据以便比较。

输出：输出目标进程证据、匹配类表、类加载器与制品对应关系、已确认差异及待查事项。每项结论区分加载来源事实与版本推断，不将sc输出当成完整字节码一致性验证，也不声称运行时问题已经修复。

来源核验日期：2026-09-08。
- 阿里巴巴 / Arthas《Arthas sc：查看已加载类》：https://github.com/alibaba/arthas/blob/be42fd932a26456988b97d863087b116de19253f/site/docs/doc/sc.md

验证说明：已核对上述公开来源及具体规则或能力；本模板尚未通过模型对比实验或线上业务实测，不能以来源品牌、仓库热度或扫描分数代替验收。

来源许可说明：Apache-2.0。本条为中文原创整理，来源内容与本模板补充要求已在正文区分。

任务：Vue 跨组件样式污染与弹层遮挡定位。基于所提供工程和业务证据完成检查，资料不足时先列出影响结论的关键问题，可以推进的部分标注假设；不要编造文件、日志、测量结果或已完成的操作。

检查 Vue 页面及组件样式，保留项目既有的缩进、现代颜色语法和浏览器适配策略。文末 FEX 资料为未定稿草案，核验提交来自 2018 年；使用其中建议时须核对当前 Vue、组件库和浏览器的实际行为。

输入：问题页面与复现路径、Vue及组件库版本、样式文件与组件源码、浏览器计算样式、构建样式顺序、目标终端。

重点检查选择器复杂度、缩写属性覆盖、!important 和视觉层级管理。以当前项目的样式生效结果确定修改方式，不机械沿用旧示例。

执行步骤：
1. 先复现一条最短路径，记录初次进入、切换路由、再次返回的差异，标出发生异常的元素和业务影响；截图只能说明外观，不能据此猜定是哪条选择器生效。
2. 从浏览器计算样式反查命中的规则、来源文件、加载顺序、继承关系及被覆盖值，区分组件库默认样式、全局样式、scoped转换和行内样式，保留可定位的证据。
3. 检查过宽选择器、相同类名、深度选择器及第三方内部类覆盖，找出影响范围超出业务组件的声明；缩写属性要核对是否顺带重置了原本只想保留的方向或字体设置。
4. 对弹窗、下拉和提示层单独分析实际挂载位置与层叠上下文，区分被父容器裁切和层级较低；不要在未确认原因前反复增大z-index或叠加!important。
5. 提出一处根因对应一项最小修改，例如收紧作用范围、取消重复覆盖、使用组件公开主题能力或调整挂载位置；涉及组件库内部结构时注明升级维护成本。
6. 复核直接访问和路由来回切换，覆盖多个同类组件、弹层叠加、长中文、滚动及目标窄屏；记录修改前后同一元素的生效规则，验证相邻页面没有被连带改变。

输出：给出复现路径、样式来源表、根因与证据、最小修改片段及受影响页面回归表。样式来源表包含元素、属性、最终值、胜出规则、来源位置与覆盖原因；不得将视觉截图通过等同于业务交互通过。

来源核验日期：2026-09-08。
- 百度 FEX《CSS 编码规范（公开草案）》：https://github.com/fex-team/styleguide/blob/b1bc701d1c92220d0eb90e88ed4ccdc3d5c979dc/css.md

验证说明：已核对上述公开来源及具体规则或能力；本模板尚未通过模型对比实验或线上业务实测，不能以来源品牌、仓库热度或扫描分数代替验收。

来源许可说明：CC-BY-4.0（仓库 LICENSE.txt）。本条为中文原创整理，来源内容与本模板补充要求已在正文区分。

请定位 故障时间段 内 受影响接口 出现的 502/504，优先找到证据，再提出最小恢复动作。

输入：部署拓扑 链路拓扑；访问与错误日志 脱敏日志；最近变更 变更记录；上游健康和资源数据 运行指标；复现请求 请求样例。

1. 对齐各节点时区与故障窗口，记录用户症状、入口响应和影响比例。先确认实际链路是否包含 CDN、负载均衡和多层 Nginx，不能仅凭响应页面判断出错层。
2. 关联同一请求的入口状态、上游状态、连接与响应耗时。区分 Nginx 无法连接、上游返回错误、上游关闭连接和等待超时；日志缺少字段时明确证据缺口。
3. 从实际代理节点核对 DNS、目标协议、端口、路由、防火墙、监听地址与 Host。分别解释拒绝连接、静默丢包及 TLS 握手异常可能产生的现象。
4. 结合应用日志查看线程池、数据库连接池、外部依赖、内存和重启记录。寻找同时间的饱和、锁等待或超时传播，不把所有 504 归因于 Nginx 超时参数。
5. 比较最近版本、配置、证书和网络策略变更。为每个候选原因给支持证据、反证、只读验证方法及影响范围；先处理最可能且可验证的原因。
6. 给恢复动作及停止条件，说明对在途请求和数据一致性的影响。修改后复测同一请求，观察约定窗口并核对业务结果；问题消失但根因未证实应分别记录。

输出：故障链路图、事实时间线、候选原因表、恢复与回退方案、修复前后指标对照。没有证据支持时不要批量重启服务，也不要宣称已找到根因。

依据与范围
- [阿里云 · CDN 回源异常排查](https://help.aliyun.com/zh/cdn/user-guide/back-to-origin-troubleshooting)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文针对 CDN，排查时应先确认实际是否有 CDN 层。

请排查 Redis Jedis 连接池容量和资源泄漏问题。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：Jedis连接池及Commons Pool管理的客户端；官方页面示例基于Jedis2.9.0，必须核对实际版本API和默认值，不将该示例作为依赖升级建议。

输入资料：Jedis与Commons Pool版本、连接池配置、借还连接代码、应用实例数量、QPS及命令耗时、实例连接上限、错误日志。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

结合应用规模、命令耗时和服务端限制评估池大小，核对借用资源是否归还；池耗尽不一定需要扩容。

检查步骤：
1. 准确区分连接建立失败、借用等待超时、连接已耗尽与命令执行超时，按首次出现时间关联应用发布、流量和数据库资源，避免把所有异常都解释为池太小。
2. 逐一核对正常、异常、提前返回和批处理路径中的资源归还，检查是否把Jedis实例跨线程共享或在长任务中持有；提出能定位泄漏的最小观测方式。
3. 统计每个应用实例、业务池与分片的连接总量，包含扩容、滚动发布时并存的实例，计算与服务端连接限制的关系，并保留必要余量。
4. 根据实际命令耗时与到达率估算所需并发连接，核对等待上限、空闲连接及检测配置；参数名称和时间单位必须匹配版本，不直接复制旧文档默认值。
5. 检查慢命令、网络、DNS和下游阻塞是否延长占用，分别说明调整池容量与消除根因的效果；需要预热时评估启动期间的集中建连压力。
6. 在代表性流量下验证借用等待、活跃连接、空闲连接、错误和服务端负载，覆盖突发、节点故障与恢复；记录每次配置变更和可撤回的旧值。

输出要求：输出异常分类、资源生命周期、连接预算、参数建议及验证结果。参数表使用“当前值｜版本依据｜建议值或区间｜推导条件｜验证指标”，不得只给一组所谓通用最优参数。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《JedisPool资源池优化》](https://help.aliyun.com/zh/redis/use-cases/jedispool-optimization)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请定位 Redis 热 Key 流量，并评审访问分散方案。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：Redis或Tair的访问热点处理；Key大小与访问热度分别判断。控制台能力和读写分离方案须核对实际实例类型与业务一致性要求。

输入资料：热点时间窗口、Key访问指标、读写比例、业务一致性要求、分片与客户端信息、峰值来源。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

定位单个 Key 所在的具体分片；选择热点复制或读写分离时，评估相应的一致性代价。

检查步骤：
1. 以业务入口和时间窗口确认访问集中在什么对象，区分单Key高频、单分片集中与全实例容量不足；离线数据大小不能作为访问频率的证据。
2. 结合应用采样与已有实例指标识别真正热点，记录读写比例、响应体大小、请求集中来源及下游行为；采集本身要有资源预算，避免无限记录所有请求。
3. 区分可短暂陈旧的读取与必须保持最新的状态决策，说明缓存未命中或热点失效时的回源承载量；写热点不要用只读扩容冒充解决方案。
4. 比较请求合并、业务限流、本地短缓存、热点副本或业务拆分，分别列出适用前提、更新成本与失败行为；不默认采用所有方案，也不只计算理论吞吐。
5. 为候选方案定义缓存更新、版本识别、失效与恢复流程，说明多副本之间可能短暂不一致时用户会看到什么，以及如何避免旧值长期残留。
6. 用正常流量、突发热点、热点切换和更新失败验证效果，记录单分片压力、用户延迟、错误和回源次数；上线先覆盖可控业务范围，保留快速撤回方案。

输出要求：输出热点证据、读写分类、候选方案对比、流程与验证矩阵。结论必须说明获得的容量改善与牺牲的一致性或复杂度，未经实测的收益仅作为待验证假设。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《Tair：大Key和热Key》](https://help.aliyun.com/zh/redis/user-guide/identify-and-handle-large-keys-and-hotkeys/)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请诊断 Redis 大 Key 问题，制定拆分、清理或转存方案。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：Redis或Tair的大对象治理；先确认版本和数据结构。UNLINK需核对Redis4.0及以后支持情况，厂商Top Key功能也有实例限制。

输入资料：实例版本与拓扑、异常指标、疑似Key样本、数据结构、增长与过期策略、业务恢复方式。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

同时检查值大小和集合规模；离线快照可辅助容量分析，但不能代表实时访问热度。

检查步骤：
1. 确认业务现象与发生时间，分别记录内存、网络、CPU、请求延迟和分片差异，先区分值过大、元素过多、无效数据增长及消费停滞，避免统称大Key后直接删除。
2. 根据现有权限选择控制台指标、业务样本或离线快照，列明数据时效和覆盖范围；需要在线扫描时设置时间窗口、节奏和停止条件，不默认全量扫描零影响。
3. 对疑似对象收集类型、大小或元素数、过期、增长速度与业务拥有方，区别样本字节长度和真实内存占用；诊断命令是否支持须对照当前版本。
4. 提出保留业务语义的拆分、压缩、清理失效成员或转存方案，逐一评估读取次数、原子性、更新复杂度与CPU成本；业务仍需要的数据不得当作无效数据清除。
5. 制定迁移期间新旧数据共存、读写切换与回退方式，删除前核对目标与恢复来源；异步删除或分批清理也要监控资源，不能承诺对线上绝无影响。
6. 在小范围演练并核对结果一致性，逐批记录数据量、失败、延迟与资源变化；根据证据扩大范围，最终为增长来源补上容量告警与生命周期管理。

输出要求：给出证据表、根因假设、方案比较、分批实施及回退步骤。每个Key使用脱敏样例，处置清单含业务归属、保留要求、验证方式和停止阈值，未识别归属的对象暂不执行清理。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《Tair：大Key和热Key》](https://help.aliyun.com/zh/redis/user-guide/identify-and-handle-large-keys-and-hotkeys/)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请定位 MySQL 慢查询与连接耗尽的原因。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：阿里云RDS MySQL或能提供对应观测数据的自建MySQL；DAS界面及增强功能不能假定所有实例具备。

输入资料：故障时间段、慢日志、实例监控、会话与事务信息、近期发布及参数变更、数据库版本与规格。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

结合资源、执行计划、批量任务和未结束事务等证据排查慢 SQL。

检查步骤：
1. 整理故障时间线，把请求延迟、错误、连接数和近期发布放到相同时间轴，区分数据库执行慢、排队等待和应用获取连接慢，不用单张CPU截图下结论。
2. 按出现时间及累计影响筛选代表性SQL，记录调用次数、扫描与返回信息、业务入口和参数；日志可能包含敏感数据，输出时只保留必要的脱敏样本。
3. 检查会话和事务等待关系，识别长时间未结束的事务、批处理及并发冲突；将阻塞者与被阻塞者分开，不能按运行时长直接批量终止会话。
4. 比较问题前后的结构、执行计划和数据分布，评估版本升级、数据增长及参数变更是否能解释现象；无法获取历史数据时标明证据不足。
5. 按影响和可逆性给出处置候选，分别说明限制入口、暂停具体任务、优化SQL或调整容量能解决什么；对每个动作规定观察指标与撤回条件。
6. 复核故障缓解后相同业务是否恢复，追踪连接和事务是否正常释放，补充缓存失效或流量再次上升的场景；把应急处置与永久修复分开验收。

输出要求：输出故障摘要、时间线、已证实原因和待查假设、处置表、修复与复核结果。每个结论关联具体观测，禁止把厂商示例阈值直接当成当前实例的正常标准。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《RDS MySQL 慢SQL问题》](https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/troubleshoot-slow-sql-statements-on-an-apsaradb-rds-for-mysql-instance)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。