hashcon

log4j2.xml配置：关闭输出代码位置（RingBuffer 满了的策略，以及增加对于 RingBuffer 的 metric 监控与暂时下线的机制通过批量 flush 进一步提高吞吐量（配置 Disruptor 的等待策略为 SLEEP，但是最好能将其中的 Thread.yield 修改为 Thread.onSpinWait (这个修改仅针对 x86 机器部署)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WxuaWLGb-1635326195436)(https://zhxhash-blog.oss-cn-beijing.aliyuncs.com/%E5%9C%A8%E8%A2%AB%E7%BA%BF%E4%B8%8A%E5%A4%A7%E9%87%8F%E6%97%A5%E5%BF%97%E8%BE%93%E5%87%BA%E5%AF%BC%E8%87%B4%E6%80%A7%E8%83%BD%E7%93%B6%E9%A2%88

本系列是 我TM人傻了 系列第三期[捂脸]，往期精彩回顾：升级到Spring 5.3.x之后，GC次数急剧增加，我TM人傻了这个大表走索引字段查询的 SQL 怎么就成全扫描了，我TM人傻了最近组里用第三方给的 SDK 搞了点开发，最近线上突然开始报错，并且发现一个特别奇怪的问题，组员和我说，代码运行到一半不走了，跳过了一段（这代码是刚参加东奥会参加跳远么？？？）。代码如下，逻辑非常简单：try { log.info("initiate client with conf: {}",.

如何监控 Log4j2 异步日志遇到写入瓶颈在之前的一篇文章中(一次鞭辟入里的 Log4j2 异步日志输出阻塞问题的定位)，我们详细分析了一个经典的 Log4j2 异步日志阻塞问题的定位，主要原因还是日志文件写入慢了。并且比较深入的分析了 Log4j2 异步日志的原理，最后给出了一些解决方案。新的问题 - 如何更好的应对这种情况？之前提出的解决方案仅仅是针对之前定位的问题的优化，但是随着业务发展，日志量肯定会更多，大量的日志可能导致写入日志成为新的性能瓶颈。对于这种情况，我们需要监控。首先想到的是

一次鞭辟入里的 Log4j2 日志输出阻塞问题的定位问题现象线上某个应用的某个实例突然出现某些次请求服务响应极慢的情况，有几次请求超过 60s 才返回，并且通过日志发现，服务线程并没有做什么很重的操作。这种情况断断续续持续了半小时左右。核心问题定位由于半小时后，服务实例恢复正常，并且出现请求极慢的次数并不太多，没有能及时打印出现问题的时候线程堆栈采集相关信息。但是，我们有自己的法宝，JFR（关于 JFR，请参考我的另一系列JFR全解）。JFR 非常适合用来事后复盘定位问题，并且配置得当的话，性能损

Log4j2相对于log4j来说扩展了多种接口，并重新定义了日志记录流程，并且引入了一些框架例如Disruptor来加速。Log4j2无论在日志记录上，还有效率速率上都相对于log4j有很大的进步，下面我们来看一些比较有意思的使用和配置的最佳实践。使用Tip1.方法参数使用Java8 lambda表达式：在java8之前，有时候log日志的参数是某个方法，可能很耗时，为了提高性