最近在微信读书上看《Java高并发核心编程（卷2）》，看到书上有这样一句话 对象一旦生产了哈希码，它就无法进入偏向锁状态。也就是说，只要一个对象已经计算过哈希码，它就无法进入偏向锁状态，当一个对象当前正处于偏向锁状态，并且需要计算其哈希码的话，它的偏向锁会被撤销，并且锁会膨胀为重量级锁 其原因在于计算对象的hashcode采用的是随机生成的方式，而由于需要保证对象的hashcode的一致性，且

我们知道，在RR的隔离级别下，为了解决幻读问题，MySQL引入了间隙锁和Next-Key Lock。这里可以参考极客时间的 MySQL 实战 45 讲-幻读是什么，幻读有什么问题？ 这一章节，讲的很是清晰透彻。 在这篇文章中，举了一个insert on duplicate key update，当有多个唯一键时的死锁问题。这里死锁的原因其实就是因为insert on duplicate key u

单点写入Multi Paxos虽然可以选举一个leader但也不是强制执行，且本身也是允许多主存在的。 而为了简化这一问题，Raft算法规定必须要有Leader节点，且任意时刻只能有1个Leader节点，所有写请求都传到Leader上，然后Leader再同步给Follower。 这样一来，问题就简化成了客户端->Leader->Follower的一个顺序链路中。 整个算法的阶段也就清晰

Caffeine相信不少同学都有使用过，其优点及一些特性网上也有很多优质的文章，这里就不再赘述。（OS：当然，我也没去钻研） 这里举一个很简单的例子

Paxos算法解析本文是阅读自《软件架构设计：大型网站技术架构与业务架构融合之道》 这本书很喜欢，里面有很多干货，本文出自11.2小节 之前看Paxos的证明的时候，就是顺着P1、P2a、P2b、P2c的证明思路往下缕，整个证明过程看着欲仙欲死。而这次看的这个文章，是从一个实际的并发场景，引出Paxos要解决的问题，倒推要解决这个问题需要提供什么能力 Paxos解决什么问题1. 一个基本的并发问题

前段时间在面试快手的时候，遇到这样一个问题，JDK1.8之后ConcurrentHashMap为什么使用synchronized而不用lock。

在学习JVM的时候，都会记住这样几个概念： 栈是线程私有的。 每个方法的调用对应着栈桢的入栈出栈。 每个栈帧包含局部变量表、操作数栈以及指向当前方法所属类的运行时常量池的引用。 局部变量是线程安全的 这些概念都不难理解也不难记住，不过吧总觉得这些就是干巴巴的概念，背下来也就过去了。今天突然意识到其实在看到这些相关概念前，就已经见到他们的身影并受到其恩惠了。

阅读《从Paxos到Zookeeper分布式一致性原理与实践》一书中有关Paxos一致性算法的部分，在此基础上增加一些个人的见解，试图讲得在大白话一点。

本篇记录了《深入理解kafka:核心设计与实现》的小概念，算是读书笔记吧，还待不断补充ing

背景项目使用了ES来替换MySQL的查询，然而在ES的实体定义过程中，我们选择了一个索引多Nested的形式来存储数据，这样就带来了一个结果就是查询出来的ES结果被打散到各个Nested的集合中去了。同时为了降低改造的耦合度，和前端的接口定义并没有修改，这就需要将层级的ES结果再打散到扁平的实体中去。因为映射的字段不同，甚至于映射的层级也不同，BeanUtils#copyProperties()方