对 Debug 的好奇 初学 Java 时，我对 IDEA 的 Debug 非常好奇，不止是它能查看断点的上下文环境，更神奇的是我可以在断点处使用它的 Evaluate 功能直接执行某些命令，进行一些计算或改变当前变量。 刚开始语法不熟经常写错代码，重新打包部署一次代码耗时很长，我就直接面向 Debug 开发。在要编写的方法开始处打一个断点，在 Evaluate 框内一次次地执行方法函数不停地调整代码，没问题后再将代码复制出来放到 IDEA 里，再进行下一个方法的编写，这样就跟写 PHP 类似的解释性语言一样，写完即执行，非常方便。 但 Java 是静态语言，运行之前是要先进...

再启 接上文 从应用到内核查接口超时（中），查到是因为 journal 导致 write 系统调用被阻塞进而导致超时后，总感觉证据还不够充分，没有一个完美的交待。而且 leader 还想着让我把问题排查过程分享给同事们，这让我更加不安，担心搞错了方向。 在以往的博客中，我的问题结论总是确定的，如果是推论的话，我会显式注明。现在的情况让我有点犯难，推论说出去担心误导了别人，而内核层的事，我只知道基本理论，有关此问题的结论还没有。 于是，我只好再次踏上查这个问题的征程。 转载随意，文章会持续修订，请注明来源地址：https://zhenbianshu.github.io 。 打印...

应用复现 接着上文 从应用到内核查接口超时（上） 继续排查导致接口超时的原因。 转载随意，文章会持续修订，请注明来源地址：https://zhenbianshu.github.io 。 Jdk 的 native 方法当然不是终点，虽然发现 Jdk、docker、操作系统 Bug 的可能性极小，但再往底层查却很可能发现一些常见的配置错误。 为了便于复现，我用 JMH 写了一个简单的 demo，控制速度不断地通过 log4j2 写入日志。将项目打包成 jar 包，就可以很方便地在各处运行了。 @BenchmarkMode(Mode.AverageTime) @OutputTime...

问题 之前的博文中说过最近在查一个问题，花费了近两个星期，问题算是有了一个小结，是时候总结一下了。 排查过程走了很多弯路，由于眼界和知识储备问题，也进入了一些思维误区，希望此问题能以后再查询此类问题时能有所警示和参考；而且很多排查方法和思路都来自于部门 leader 和 组里大神给的提示和启发，总结一下也能对这些知识有更深的理解。 这个问题出现在典型的高并发场景下，现象是某个接口会偶尔超时，查了几个 case 的日志，发现 httpClient 在请求某三方接口结束后输出一条日志时间为 A，方法返回后将请求结果解析成为 JSON 对象后，再输出的日志时间为 B， AB之间的时间差会...

由来 最近有个需求需要统计一个方法的耗时，这个方法前后各打出一条日志，类似于 [INFO] 20180913 19:24:01.442 method start/end unique_id，unique_id 是我们框架为了区分每一个请求而生成的唯一ID。 由于在高并发场景下， start 和 end 的日志并不一定是挨着的，很可能方法执行期间，又有其他的日志输出了出来，于是产生了这样的日志： [INFO] 20180913 19:24:01.442 method start aaa [INFO] 20180913 19:24:01.452 method start bbb [IN...

前言 不久前在部门周会上分享了 Hystrix 源码解析之后，就无奈地背上了”专家包袱”，同事们都认为我对 Hystrix 很熟，我们接触 Hystrix 更多的还是工作中的使用和配置，所以很多人一遇到 Hystrix 的配置问题就会过来问我。为了不让他们失望，我把 Hystrix 的配置文档 仔细看了一遍，将有疑问的点通过翻源码、查官方 issue、自己实验的方式整理了一遍，这才对 Hystrix 的配置有了一定的了解。 在了解这些配置项的过程中，我也发现了很多坑，平常我们使用中认为理所应当的值并不会让 Hystrix 如期望工作，没有经过斟酌就复制粘贴的配置会让 Hystrix ...

闲话 最近部门开始了轰轰烈烈的的”人人要分享”活动，每个人都要从待选主题里选一个来分享。由于我之前在做请求合并需求时看了些 Hystrix Collasper 的源码，于是选了 《Hystrix 源码解析》。 原以为人这么多慢慢排就是了，我每个周末抽出一些时间来看一下就行了，没想到被 leader 排到了组里的第一个，真的是赶鸭子上架，紧赶慢赶，上周六还加班到晚上十二点，总算捣腾出来一个 PPT。不过有些感慨三年的博客没白写，写 PPT 并没有那么痛苦。 痛苦的是读 Hystrix 源码的过程。在此之前我并没深入了解过 Hystrix 源码的主体部分，正式开始看后才发现选了个坑。H...

前言 最近在了解 Java 效率测试库 jmh 时，遇到一个问题，我想在 jmh 里使用项目里的某个 Spring Bean，但我是在本地单独运行的 jmh，而这个 bean 创建却需要依赖很多我们项目里的配置，这就出现了一个非常尴尬的局面，如果在项目使用 jmh，每次测试同步到测试机，稍稍改动一下就要重启一两分钟；而如果我自己创建一个对象的话又要自己手动配置很多项目里的依赖。 而且，之前一次调试中，我在 debug 环境想查看一下此时 beanFactory 里是否有否个 bean，却因为获取不到 beanFactory 失败，这使得我对 Spring 核心的理解需求更迫切了。 ...

将相似或重复请求在上游系统中合并后发往下游系统，可以大大降低下游系统的负载，提升系统整体吞吐率。文章介绍了 hystrix collapser、ConcurrentHashMultiset、自实现BatchCollapser 三种请求合并技术，并通过其具体实现对比各自适用的场景。 前言 工作中，我们常见的请求模型都是”请求-应答”式，即一次请求中，服务给请求分配一个独立的线程，一块独立的内存空间，所有的操作都是独立的，包括资源和系统运算。我们也知道，在请求中处理一次系统 I/O 的消耗是非常大的，如果有非常多的请求都进行同一类 I/O 操作，那么是否可以将这些 I/O 操作都合并到一...

文章介绍了spring-boot中实现通用auth的四种方式，包括 传统AOP、拦截器、参数解析器和过滤器，并提供了对应的实例代码，最后简单总结了下他们的执行顺序。 前言 最近一直被无尽的业务需求淹没，没时间喘息，终于接到一个能让我突破代码舒适区的活儿，解决它的过程非常曲折，一度让我怀疑人生，不过收获也很大，代码方面不明显，但感觉自己抹掉了 java、Tomcat、Spring 一直挡在我眼前的一层纱。对它们的理解上了一个新的层次。 好久没输出了，于是挑一个方面总结一下，希望在梳理过程中再了解一些其他的东西。由于 Java 繁荣的生态，下面每一个模块都有大量的文章专门讲述。所以我...