乐天派

通过引入zipkin-spring-boot-starter（下文简称zipkin-starter）依赖，小伙伴们可以分分钟让应用集成链路跟踪能力。随着集成链路跟踪的应用数量持续增加，作为中间件依赖的zipkin-starter开始面临的各种框架的兼容性问题。今天就聊一下dubbo高版本（2.7.5&2.7.6，两个版本兼容性问题相似，下文只对2.7.6进行分析）的兼容性问题：因zipkin-starter默认生成的Config覆盖dubbo自身Config，导致配置文件中的dubboConf.

问题描述线上突然出现Dubbo超时调用，时间刚好为Consumer端设置的超时时间。有好几个不同的接口都报超时了第1次调用超时，第2次（或第3次）重试调用非常快（正常水平）Dubbo调用超时的情况集中出现了3次，每次都是过一会自动恢复排查排查日志看到调用超时，首先就拿着traceId去服务提供方查日志。奇怪的是，在服务提供方的业务日志里面，只有正常的调用日志（耗时正常），没有超时调用的日志。从正常的调用日志里面看，一切都是正常的，看不出所以然。给人的感觉就是超时那次请求的调用没有达到

HashMap死循环我第一次听到HashMap会有死循环的问题是两年前，我们团队有一个学长实习回来给我们说有个同事因为没有注意到HashMap在多线程可能会造成死循环而造成了一些损失。后面就对这个问题很感兴趣，然后趁着今天整理资料就顺便记录一下，虽然偷懒了，逃 = -=什么造成的我们知道HashMap不是线程安全的，那么具体到代码，是哪部分代码的原因呢？ 我本来想写一篇博客介绍如

对于刚接触多线程的初学者来说，会发现很多框架都出现过ThreadLocal的身影，知道这个类是为了避免在多线程条件下出现资源竞争的问题。但是，在没有深入了解线程之前，更多的是知道ThreadLocal的目的是什么，对于是什么、怎么用、运行原理相信都是一个很模糊的概念，我希望这篇博客能够揭开困扰大家已久的谜团，以及带给大家一些相关知识。说到要分析东西的时候，我觉得有一个比较好的方法可以帮助大家：不管分

为什么标题叫做对于AQS的一点理解呢，因为感觉自己还没有达到能够对AQS理解透彻,哈哈。这段时间在总结以前学过的东西，发现大牛写的东西真的是厉害，越学越谦虚，越学越感觉自己还有好多好多的东西要学。

今天看到一篇博客：jdk1.8的HashMap和ConcurrentHashMap，我想起了前段时间面试的一个问题：ConcurrentHashMap(JDK1.8)为什么要使用synchronized而不是可重入锁？我想从下面几个角度讨论这个问题：锁的粒度 首先锁的粒度并没有变粗，甚至变得更细了。每当扩容一次，ConcurrentHashMap的并发度就扩大一倍。Hash冲突 JDK1.7