-
金额 127 元的订单对账全对,128 元的却全部失败:我在 Java 里被 Integer 的 -128~127 缓存和 == 坑出一身冷汗的对账事故复盘
订单对账系统突然抽风:金额 127 元以下的全部正常,128 元以上的几乎全部判为"金额不一致"被打回。127 和 128 一线之隔命运两端,真凶是我用 == 比较了两个 Integer——而 Integer.valueOf 默认缓存 -128~127,缓存内是同一对象 == 碰巧为 true,缓存外各自 new 出新对象 == 就为 false。这篇复盘从 == 比引用、自动…- 2
- 0
-
.NET 8 数据网关 P99 每 18 分钟飙到 4.2 秒的 5 天复盘:async 三连击反模式 + ThreadPool 饥饿定位 + 4 种修法 + 12 条 async 纪律
我们的 .NET 8 + ASP.NET Core 实时数据网关每 18 分钟出现 P99 4.2 秒尖刺,5 天定位到 .Result 同步阻塞 + 缺 ConfigureAwait + 自定义同步 Logger 三连击导致 ThreadPool 饥饿,4 种修法把 P99 稳定回 28ms。- 2
- 0
-
Python 多进程 fork 后 logger 卡死的真实事故:6 层因果链 + 三种修法
一台数据处理机突然不出日志,32 个 worker 全部卡在 acquire() 上。py-spy 抓栈定位到根因:multiprocessing 默认 fork 复制了父进程持锁瞬间的状态,子进程继承了一把永远没人释放的 logger 锁。从症状到根因隔着 6 层因果链,本文给出 spawn / forkserver / QueueHandler 三种修法,以及全套 fork-safety li…- 2
- 0
-
一次 Python 字典在循环里加 key 引发 RuntimeError 的复盘:4 种修法 + 性能基准
会员中心定时任务凌晨 3 点抛 RuntimeError: dictionary changed size during iteration,改成 list(d) 后又漏了 4.2 万条数据。本文复盘 6 小时排查 + 72 小时漏数,讲清 4 种修法的性能 / 安全 / 适用场景,附决策树和团队事后立的 4 条规矩。- 0
- 0
-
asyncio event loop 被同步代码卡死的真实事故:P99 从 80ms 飙到 12s 的 6 小时复盘
一个隐藏在 async 函数里的 requests.get() 调用,把订单查询服务的 P99 从 80ms 推到 12 秒。本文用 1 万字+ 的篇幅完整复盘 6 小时排查过程:py-spy 抓栈、事故时间线、5 种修法横向对比、Prometheus loop lag 监控、Kubernetes 探针、AST 静态扫描规则,以及事故后我们对 47 个 Python 服务做的全面体检。- 8
- 0
生产事故
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×