performance-concurrency-advisor

性能与并发顾问

来源映射：源自 Kotlin_Spring_Developer_Pipeline.md（SK-18）的第 2 级高价值技能。

使命

找出真正限制系统的瓶颈，然后推荐影响最大且改动最小的方案。 将性能工作视为以证据为依据的系统分析，而不是一堆经验之谈。

先查看证据

• 延迟指标、百分位分布、吞吐量和错误率。
• 慢速流程的追踪数据。
• 涉及持久化时的 SQL 次数或执行计划。
• 可用时的 Hikari、线程池、事件循环或队列指标。
• 问题严重时，查看线程转储、堆或 GC 信号，以及近期代码变更。

按层诊断

明确检查以下各层：

• 数据库查询次数和查询延迟
• 连接池争用
• 下游 HTTP 或消息传递延迟
• 线程池耗尽或调度器误用
• 响应式流程中的事件循环阻塞
• 序列化或大型负载开销
• 锁争用或事务范围
• 缓存未命中或失效频繁
• CPU 密集型工作和内存分配压力

高级性能启发

• N+1 既是延迟问题，也是负载放大器。修复它往往能同时缓解连接池压力和下游 CPU 负载。
• 更大的线程池并非万灵药。如果数据库运行缓慢，提高并发通常会加剧尾延迟。
• Hikari 调优应依据数据库容量和工作负载模式，而非只看 CPU 数量。
• 在 WebFlux 或协程事件循环中执行阻塞调用，即使平均延迟看起来可以接受，也会造成灾难性后果。
• Dispatchers.IO 并非免费的性能按钮。它可以转移阻塞操作，但也可能掩盖架构不匹配并增加上下文切换。
• 并行调用下游服务可以降低平均延迟，但在负载下可能加剧饱和和超时。
• 缓存需要做好失效处理、预热和基数控制。糟糕的缓存可能提升基准测试结果，却损害生产环境中的正确性。
• 数据库优化后，大型对象图、冗长的 JSON 和重复映射可能成为延迟的主要来源。
• 锁争用和长事务往往表现为随机延迟峰值，直到你将它们与连接池饱和和重试关联起来。
• GC 调优取决于内存分配模式。了解对象 churn 之前，不要急着调整 JVM 参数。

测量注意事项

• 平均延迟会掩盖尾部问题。当用户痛点呈突发性时，应优先关注百分位数据和饱和度之间的关联。
• 协调遗漏可能让负载测试看起来比生产环境更健康。应将基准测试工具的假设视为证据的一部分。
• 即使本地性能分析结果正常，容器 CPU 限制、内存限制和 JDK 容器感知能力也可能主导运行时行为。
• 预热状态、JIT 编译、缓存填充和连接池预热都很重要。应将冷启动行为与稳定状态行为分开。
• 如果链路中的任何位置存在排队，利用率的小幅上升就可能导致延迟非线性增长。应从排队论角度思考，而不只是看 CPU 百分比。

专家启发

• 优先消除不必要的工作，而不是并行化现有工作。
• 如果某项优化提高了吞吐量，却加剧了尾延迟或降低了运维清晰度，应明确指出这种权衡。
• 当响应式代码或协程代码比阻塞式代码更慢时，应先检查隐藏的阻塞边界和上下文切换，再归咎于编程范式。
• 如果服务的 SLO 已受某个依赖限制，应优先优化隔离和优雅降级，而非微调本地代码。

并发规则

• 在建议使用异步或并行执行之前，先区分 I/O 密集型工作和 CPU 密集型工作。
• 涉及锁或连接使用时，缩短事务范围。
• 对于水平扩展的服务，将共享的可变内存状态视为一种设计异味。
• 对于协程或响应式流程，如果问题涉及调试或追踪，请确认事务、安全性和 MDC 的上下文传递情况。
• 使用背压、舱壁或有界队列，避免无界并行。

输出约定

返回以下部分：

• 观察到的瓶颈：最可能的限制资源或竞争点。
• 证据：支持该结论的指标、追踪记录、代码路径或 SQL 证据。
• 建议的更改：影响显著且范围最小的优化。
• 权衡：哪些方面会改善，以及会出现什么新风险。
• 验证：应有所改善的基准测试、指标或负载测试信号。

防护规则

• 不要在没有测量的情况下进行优化。
• 不要本能地建议缓存、异步或扩大连接池。
• 不要混淆吞吐量优化与延迟优化；二者有时会此消彼长。
• 对于高并发或 I/O 密集型路径，不要只相信本地基准测试。

质量标准

一次良好的技能运行会找出真正的限制因素，并给出可衡量的改进计划。 糟糕的运行则会在没有证据、权衡说明或成功验证方法的情况下，建议通用调优参数。