Codeium写性能分析问题提示词有哪些具体问法

用Codeium准确定位线上服务瓶颈，关键是把分析路径锁死。你问它“为什么响应变慢”，它大概率回你“检查CPU”“优化SQL”“加缓存”——这些建议放之四海而皆准，但根本没法落地。因为提示词没给方向，AI就只能在运维常识库里随机采样。要想让它干实事，得这么来：JVM堆泄漏点靠JFR dump按Retained Size排序，查GC Roots引用链；GC毛刺用G1日志算Old区增长速率，或者用JFR事件链分析分配峰值；线程阻塞就聚焦BLOCKED线程的锁地址，定位持有者，再给出细粒度锁改造建议。

说白了，提示词里不给出具体路径，AI就只会甩通用方案。下面把每一步拆开讲。

锁定JVM堆内存泄漏点

打开VisualVM或JFR导出的dump文件，切到“Heap Dump”视图，点“Classes”标签，按“Retained Size”降序排。排第一的类很可能是元凶——比如com.example.OrderProcessor。右键它，选“Merge Shortest Paths to GC Roots”，勾上“with all references”。展开后重点看静态字段和线程局部变量，比如ThreadLocal实例没调用remove()，这种最典型。

要是发现ja va.util.HashMap$Node对象占Retained Size超过65%，而且key是String、value是byte[]，那基本断定是缓存没设淘汰策略，等着OOM吧。注意：必须用JFR 8.0以上版本导出的.jfr文件，旧版jmap -histo输出根本看不到GC Roots引用链，问了也白问。

定位GC停顿毛刺根源

这里给两条路，任选其一。

把gc.log里最近一次Full GC前3秒内的G1 Evacuation Pause日志复制出来，告诉Codeium只做三件事：第一，统计每行[Eden: …, Survivor: …, Old: …]中Old区增长速率（MB/s）；第二，对比同一时段Prometheus抓取的jvm_memory_used_bytes{area="old"}指标斜率；第三，如果两者偏差超过12%，判定为Old区碎片化，需要加参数-XX:G1MixedGCLiveThresholdPercent=85。

把JFR里“Garbage Collection”事件详情扔给Codeium，让它提取“G1EvacuationPause”事件的duration字段，并关联同一时间戳的“Allocation Rate”事件。如果allocation rate峰值出现在evacuation pause开始前800ms内，且该时段分配量超过200MB，说明突发大对象分配触发了并发标记失败（Concurrent Mode Failure）。再次强调：不提供JFR事件ID或时间戳，AI没法做关联分析，结果一定是泛泛而谈。

识别线程阻塞真实源头

从threaddump里复制完整文本，开头加一句指令：“请只分析BLOCKED状态线程的waiting on lock地址，忽略TIMED_WAITING和RUNNABLE线程。”这一步是为了屏蔽噪声。

找出所有waiting on 0x00000007c0a1b2d0的线程，然后搜这个锁地址被谁持有（看Locked ownable synchronizers）。假设持有者是pool-1-thread-3，并且它正在执行com.example.PaymentService.process()，那支付核心链路必然存在单点锁竞争。修复方案只有一个：把synchronized(this)块拆成细粒度锁，比如用ConcurrentHashMap代替HashMap缓存paymentId→status映射。这个建议可以直接写进代码，可验证、可落地。