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

最近发现一个应用，使用默认的 JFR 配置，发生了类似于雪崩的现象，这里记录下，引以为戒。Key takeawaysJFR 的线程堆栈 dump 采集默认周期是everyChunk，也就是每次新建一个Chunk就会采集一次。默认每个Chunk大小为 12M，在线程比较多的时候，堆栈 dump 可能大于 12M，导致 JFR 一直切换新的 Chunk，然后又触发evenryChunk导致无限循环而雪崩。对于 JFR 默认事件采集配置（位于JDK目录/lib/jfr/default.jfc），每个采.

问题场景在某一时刻，某个微服务的某个实例 CPU 负载突然飚高：同时建立了很多数据库链接：其他实例没有这个现象。问题定位由于建立了很多数据库链接，猜想可能是数据库比较慢，查看数据库这段时间的 SQL 统计，发现数据库并不慢：其中这个微服务这段时间的热点 SQL，执行并不慢。那么问题出在了哪里呢？可能是由于 GC，可能是由于 safepoint，还有可能是获取锁时间过长（参考：Java 监控 JFR全解），我们 dump 一下 JFR 并查看其中的 safepoint，GC 以及 Monit

本文基于OpenJDK 11最近使用Spring Cloud Gateway的时候，遇到了一个奇怪的问题：线上有3个 API 网关实例，压力均衡，平稳运行3天后，突然有一个实例，CPU飚高，并且响应时间增加很多，从几十毫秒涨到了几分钟。线上是 k8s 管理容器，立刻停掉了这个 pod，重建，恢复正常。线上我们开启了 JFR 记录（可以参考我的另外系列文章：Java 监控 JFR），通过 JMC 查看下出问题的 JFR 记录。首先我们来看 GC，我们的 GC 算法是 G1，主要通过 G1 Gar.

BUG背景JDK: 11.0.4Spring Cloud Finchley.SR3相关配置：#开启hystrixfeign.hystrix.enabled=true#关闭断路器hystrix.command.default.circuitBreaker.enabled=false#禁用hystrix远程调用超时时间hystrix.command.default.executi...

最近发现线上的某个查询微服务，发生了一个奇怪的问题，GC次数突然变多，GC的时间耗费也变多。并不是一直有这个问题，而是每隔一段时间就会报出来的。查看jstat -gcutils 10000：有类似于如下的：S0 S1 E O M CCS YGC YGCT FGC FGCT GCT0.00 100.00 100.0...

本文基于Spring Cloud Fincheley SR4， Arthas 3.1.4最近发现业务上返回慢，并且feign的fallback被触发了。查看日志，发现触发了重试，是什么触发的重试呢，通过异常堆栈发现：Caused by: feign.RetryableException: connect timed out executing GET http://test-service...

问题现象应用用druid连接池，设置慢SQL时间为500ms。在线上应用报了一些但是不多的慢查询日志，并且这个慢查询日志居然是单条插入的语句。后台数据库是MySQL，有查询统计日志监控，并没有发现很慢的插入语句。觉得很奇怪，需要仔细定位下问题定位为了确认问题，搭建压测环境，并在应用和MySQL所在的机器上进行抓包分析。压测开始后，又发现了很多是单条插入语句的慢查询日

问题现象某些前端发来的请求会在前端加密发送到网关，并在网关解密之后发到真正的微服务，并将结果加密返回给前端。 实现网关加密后，发现一次加密请求后，紧接着的非加密GET请求，就会出现400的错误。再发一次相同的GET请求，就会正常，观察后端微服务的收到网关请求的accessLog，发现接收到的请求解析有问题：## 400的请求- - - [04/Jan/2018:19:48:30 +

记一次 JAVA 的内存泄露分析 转载出处：https://github.com/jasonGeng88/blog当前环境jdk == 1.8httpasyncclient == 4.1.3代码地址git 地址：https://github.com/jasonGeng88/java-network-programming背景前不久，上线了一个新项目，这个项目是一个压测系统，可以简单的看做

转载出处：https://github.com/jasonGeng88/blog当前环境jdk == 1.8httpasyncclient == 4.1.3代码地址git 地址：https://github.com/jasonGeng88/java-network-programming背景前不久，上线了一个新项目，这个项目是一个压测系统，可以简单的看做通过回放词表（http请求数据），不断地向服

SpringRedisTemplate针对这个Scan进行了封装，示例使用（针对最新库spring-data-redis-1.8.1.RELEASE）：Set<Object> execute = redisTemplate.execute(new RedisCallback<Set<Object>>() { @Override public Set<Object> doInRedis(

问题现象ETCD作为我们管理面（基于Java）的异步任务同步媒介，在管理面压力测试时，发现任务状态不更新了。问题定位流程而业务线程日志正常（INFO级别），数据库没有死锁，并且top -c命令和sar命令等查看CPU，内存，硬盘IO都正常。 于是，利用jstack定时十秒打印线程方法调用栈，打印六次。 发现定时线程方法栈很奇怪： 发现这个线程池里面的所有线程都处于WAITING状态，并且调