范文多多

使用 @Async 把耗时任务丢到线程池执行，是 Spring 项目里最常见的异步改造手段。但很多人第一次接入时会遇到一个诡异现象：方法明明加了 @Async，日志里的线程名却还是 http-nio-8080-exec-1，接口照样被阻塞，异步等于没加。更麻烦的是，这个问题在单元测试里往往测不出来，上线压测时才暴露。 根本原因几乎都指向同一件事：@Async

线上排障时最常被问的一句话是「这个服务的内存是什么时候涨上去的」。监控平台往往只保留 7～15 天的高精度曲线，而内存泄漏的斜率可能一个月才看得出来；容器重启后历史数据又断了一截。psutil 是 Python 里直接读 /proc 的轻量库，几十行代码就能在自己的机器上落一份「按分钟采样、按天归档」的 RSS 趋势文件，不受监控系统保留策略限制。下面这份脚

软删除是业务表的常见设计：加一个 deleted_at 或 is_deleted 字段标记删除，查询时过滤。真删除会绕过这个设计，所以大部分团队都会遇到同一个问题——原本在 email、username、order_no 这类字段上的唯一索引，在软删除之后不再"正确"：删除一条记录后再次注册同一个邮箱会撞唯一键，报 Duplicate entry 'a@b.

用 array_walk 配合递归去"顺手"修改嵌套数组，是 PHP 里一个特别容易踩雷的写法。表面上看，回调函数里写了 $value = ...，跑完 print_r 却毫无变化；或者小心翼翼加上 &$value，结果顶层改了、深层没改；再或者想用 array_walk_recursive 一把梭，却发现它拿不到父级键名，也没法直接替换整个子树。这

这道题在面试里出现的频率不低，但绝大多数候选人的回答停留在「脑裂就是两个 master，会丢数据」这个层面，再往下问「丢多少、什么时候丢、窗口多长、怎么算」就答不上来了。实际上 Redis 本身并不具备自动的脑裂防护（Sentinel 的 quorum 只能降低概率，不能消除），数据丢失窗口是有明确数学边界、可以被量化和判定的。这篇文章把窗口的构成拆开算清楚

线上经常遇到这样的场景：监控面板显示 Pod 内存 2.3GiB，而 requests 只给了 512Mi，limits 是 1Gi，于是怀疑监控出错或容器逃逸；另一种情况是扩容时 kubectl top 的值远低于 requests，HPA 一直不缩容，节点资源被白白占着。这两个数据来自完全不同的链路——kubectl top 读的是 metrics-se

商品详情页要同时拿到价格、库存、促销、评价四份数据，四个下游接口串行调用 800ms 起步，改成并行之后 P99 掉到 220ms。但并行带来的新问题是：只要有一个接口卡住，整页就跟着卡住。给每个 future 单独 orTimeout 只能解决单点超时，它抛出的 TimeoutException 会让 allOf 立刻异常结束，其余还在跑的请求白白浪费，而

写 Rust 的时候，只要函数签名里出现 & 而返回值又是引用，编译器就很可能甩出一串 error[E0106]: missing lifetime specifier。新手常见的反应是随手加 'a，加完发现 borrow checker 又在调用点报错，于是继续加，最后把一个本来十行的函数写成生命周期标注的涂鸦墙。 真正需要理解的是：省略规则（lifeti