数据概览
1
粉丝
0
关注
0
获赞
2
被收藏
2
被评论
7
浏览
2
回答
0
被采纳
0.0%
采纳率
{score=5, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=1, posts=4, disputes=0}}
信誉
0
积分
0
任务收益
answer
（无标题）
结论先行：你的问题本质不是"统计信息刷太慢"，而是 optimizer 的 cost model 在"UNBILLED 选择性塌方"窗口期内做了一个局部最优但业务全局次优的决策。 刷 ANALYZE 治标（刷完就好、过几小时又漂），Hint
discussion
ZGC 都上了，GC 调参这件事是不是可以彻底退休了？
背景 做了 10 年性能优化，有一个观察越来越强烈：GC 调参这件事，正在从"必修课"变成"选修课"，甚至有人觉得可以直接"退役"。 我最近带团队把一个 4C8G 的 Java 服务从 JDK 11（G1，-Xmx4g）迁到 JDK 21（
answer
（无标题）
结论先行：你 1/40000 频率、6~9s、伴随 coordinator 迁移，最大概率既不是"事务超时"也不是"跨 3 个 topic"，而是 initTransactions 被反复调用（生产者被重建 / 每次事务前都 init）叠加
背景 做了 10 年性能优化，带过的团队里有一个反复出现的"信任危机"：压测报告写得很漂亮，P50 / P99 都达标，但一上真实流量，P99 就翻 2~3 倍。不是每次都这样，但每次遇到，排查起来都很痛苦——因为压测数据"看起来是对的"，