今天偶然在头条上看见一个基于Zk的分布式锁的推荐，觉得讲的不错，想起来自己在分析分布式锁的时候对于Zookeeper锁的分析没有完善。所以今天来补一篇。分布式锁Zookeeper的节点类型1. 持久节点节点创建后就会一直存在，直到主动删除，不会因为创建改节点的客户端会话消失而消失。2.持久顺序节点持久的，顺序节点，Zk会维护这个时序，记录子节点的创建的先后顺序。3.临时节点临时节点的生命周期和客户

今天我们来看死锁，死锁的一般场景大家都能想到，只要你不是很菜，A获取资源Z之后再获取资源X，B获取资源X之后再获取资源Z，这样就造成了死锁。解释：死锁是指两个或两个以上的事务在执行过程中，因争夺锁资源而造成的一种互相等待的现象。解决办法：1.超时。InnoDB中设置了超时时间，参数为innodb_lock_wait_timeout。2.wait-for graph（等待图）由于超时机制虽然简单，但

说起分布式的概念，首当其冲就是CAP理论，即满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。但是CAP理论告诉我们，任何系统只能满足其中两个，所以都要求去做取舍。那么人们常说的一般都是，需要牺牲一致性来保证系统的高可用性，只要保证系统的最终一致性，并且允许的时间差值能够被接受就行。对于这个，本人的体会就是订单系统，对于

java规范规定了对基本数据类型的操作必须是原子性的，但是long和double除外。但是对于volatile 修饰的long和double，读写必须为原子的。但是规范没有规定怎么去实现，现今的虚拟机都是把32位作为原子性操作。但是对于64位确没有，因此64位虚拟机操作long和double时，会出现两次写操作，这就造成了错位可能，因此在64位上操作共享的long和

锁的消除出现的时机：虚拟机即时编译期运行时。出现的原因：主要判断依据就是来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当做栈上的数据对待，认为它们是线程私有，同步锁无须进行。出现的典型例子：本身对于String的连接操作JVM会转化成StringBudiler进行连接，既然转化成了sb，那么其实sb是一个局部变量，对于append操