why技术

你好呀，我是歪歪。 两年前我曾经发布过这样的一篇文章《我是真没想到，这个面试题居然从11年前就开始讨论了，而官方今年才表态。》 文章主要就是由这个面试题引起：

你好呀，我是歪歪。 事情是这样的，上周有个读者找我，给我抛出了这样的一个问题： 问题中涉及到的文章分别是这两篇： 《有的线程它死了，于是它变成一道面试题》 --- why技术 《线程池中线程异常后：销

你好呀，我是歪歪。 昨天分享了一下《腾讯云 4 月 8 日故障复盘及情况说明》，较为详细的描述了故障前后的具体情况。 按照惯例，这种大公司的故障说明，歪师傅都是要好好看一下的。 一来是看看有没有可以学

你好呀，我是歪歪。 踩坑了啊，最近踩了一个 lombok 的坑，有点意思，给你分享一波。 我之前写过一个公共的服务接口，这个接口已经有好几个系统对接并稳定运行了很长一段时间了，长到这个接口都已经交接给

你好呀，我是歪歪。 这篇文章给大家盘一下“分支预测”这个听起来玄乎，但是对写业务代码没有任何卵用的小技巧。 上周不是发了这篇文章嘛：《十亿行数据，从71s到1.7s的优化之路。》 这里面就提到了一嘴：

你好呀，我是歪歪。 春节期间关注到了一个关于 Java 方面的比赛，很有意思。由于是开源的，我把项目拉下来试图学（白）习（嫖）别人的做题思路，在这期间一度让我产生了一个自我怀疑： 他们写的 Java

你好呀，我是歪歪。 先给大家道个歉： 上周不是发布了这篇文章嘛：《三个烂怂八股文，变成两个场景题，打得我一脸懵逼。》 其中第一个关于线程池的场景，经过读者提醒可能有问题，我又一次用尽浑身解数分析了一波

你好呀，我是歪歪。 这篇文章来盘一下我最近遇到的两个有意思的代码案例，有意思的点在于，拿到代码后，你一眼望去，没有任何毛病。然后一顿分析，会发现破绽藏的还比较的深。 几个基础招式的一套组合拳下来，直接

你好呀，我是歪歪。 Spring 的事件监听机制，不知道你有没有用过，实际开发过程中用来进行代码解耦简直不要太爽。 但是我最近碰到了一个涉及到泛型的场景，常规套路下，在这个场景中使用该机制看起来会很傻

你好呀，我是歪歪。 前两天在社区冲浪的时候，看到首页推了一篇文章： 我看了一下，文章写的还是挺好的，案例经典，思路清晰，行文流畅。 你可以看一下，文章写的基本没啥毛病，有些小瑕疵在评论区指出了，问题也

你好呀，我是歪歪。 前两天在一个技术群里看到有人抛出一张图片，提出了这样的一个问题： 了解了一下背景，是批量任务触发，从订单表中查询出“处理中”状态的订单，订单可能属于不同的通道，所以需要调用不同通道

你好呀，我是歪歪。 事情是这样的，前段时间有个人加我微信，说有个文案想要找我帮他们推广一下： 链接点进去后，我一看标题是这样的： 心里就有数了，知道这个相关的内容肯定是诈骗信息。 整个文案的内容大概是

你好呀，我是歪歪。 定时任务，大家在开发的过程中肯定都是接触过的。 歪师傅面试的时候关于定时任务一般都会问这样的一个问题：在实际开发的过程中，你们是如何避免定时任务重复执行的呢？ 什么意思呢？ 我给你

比如“两会”期间就是重保，原则上重保期间，甚至重保前一周都是不能进行服务投产的，不会设定投产窗口。如果一定要投产，走特殊申请，提高审批级别，报备投产内容和步骤，需要大领导签字同意之后才能投产。

你好呀，我是歪歪。 关于 RPC 调用，大家肯定都是比较熟悉的了，就是在微服务架构下解决系统间通信问题的一个玩意。 其中的典型代表之一就是 Dubbo 了： 在微服务架构下，我们针对某个 RPC 接口

你好呀，我是歪歪。 前几天我在网上冲浪，看到一个哥们在吐槽，说他工作三年多了，没使用过多线程。 虽然八股文背的滚瓜烂熟，但是没有在实际开发过程中写的都是业务代码，没有使用过线程池，心里还是慌得一比。

你好呀，我是歪歪。 昨天晚上语雀发布了关于 10 月 23 日的故障公告，公告中关于故障的时间点梳理如下： 14:07 数据存储运维团队收到监控系统报警，定位到原因是存储在升级中因新的运维工具 bug

你好呀，我是歪歪。 昨天语雀凉了一下午，哦，不对，下午一般是指 12 点到 18 点的这 6 个小时。 语雀是从下午 14 点到晚上 22 点多，凉了 8 小时有余。 这故障时长，放眼整个互联网也是炸

你好呀，我是歪歪。 这次来盘个小伙伴分享给我的一个面试题，他说面试的过程中面试官的问了一个比较开放的问题： 他觉得自己没有答的特别好，主要是没找到合适的角度来答题，跑来问我怎么看。 我能怎么看？ 我也