乒乓狂魔

2017/03/17 16:54

发表了博客评论：

刚才又仔细看了下，是我疏忽了，多谢指点

jdk1.8的HashMap和ConcurrentHashMap

2017/01/20 18:39

发表了博客评论：

workQueue.offer方法返回false就是任务队列已满，无法存放

线程池源码分析-ThreadPoolExecutor

2017/01/06 11:08

发表了博客评论：

链表查询、添加操作的时间复杂度是O（n），红黑树查询、添加的时间复杂度是O（logN），当数据越来越多自然就选择红黑树了

jdk1.8的HashMap和ConcurrentHashMap

2017/01/04 12:03

发表了博客评论：

确实内容很多，需要多花点时间来搞清楚，我写都花了很长时间来写的

jdk1.8的HashMap和ConcurrentHashMap

2016/12/06 12:14

发表了博客评论：

嗯，用词不当，可能大家也不会在意

招募有志青年

2016/12/05 21:13

发表了博客评论：

怎么加入，文中都已经说了

招募有志青年

2016/11/08 19:04

发表了博客评论：

paxos我也暂时先放下，之后有空再研究研究细节。如果想实现一个分布式一致性的方案，的确是非Raft莫属。如果想对分布式一致性有更加深刻的理解，还是需要去仔细体会paxos的。

Raft对比ZAB协议

2016/11/04 09:38

发表了博客评论：

leader选举一般有2种场景：
1 大家都处于选举状态，大家投票进行选举
2 leader选举已经完成，部分server才开始发起投票请求，这时候就相当于加入一个已经完成leader选举的集群

A是不会等C的信息的，只要A和B已经选出来一个leader了，那A和B就会一个进入leader一个进入follower，由于网络的原因导致C此时才发送投票请求，这种情况下就属于C加入一个已经完成leader选举的集群。

针对这种情况，更多的是C去学习上述leader投票：A和B收到C的请求后，A和B会把当前已经选举出来的leader信息如B发送给C，C收到投票回复后，会把非LOOKING状态的server的回复存放在outofelection集合中，同时判断的是上述leader投票是否过半，过半则认为ok了，C也学习到了目前集群的leader信息，同时呢，会更新C的electionEpoch，也就是说c的electionEpoch被重置了

ZooKeeper的一致性算法赏析

2016/11/04 08:47

发表了博客评论：

上面已经详细介绍了，不仅仅是过半这么简单，还要处理很多细节问题，你还是把上面仔细看下

ZooKeeper的一致性算法赏析

2016/11/03 15:46

发表了博客评论：

它是选举算法FastLeaderElection的一个属性，在zookeeper的server启动的时候就会创建选举算法，该值初始是0，之后该server每执行一次选举，electionEpoch 就会自增，同时在选举的时候，一旦别人的投票中的electionEpoch 比自己的大，也会更新自己的electionEpoch来和别人保持一致

ZooKeeper的一致性算法赏析

2016/11/02 20:07

发表了博客评论：

这也只是基础，找到自己的方向后还要深入了解

java技术栈

2016/10/10 15:54

发表了博客评论：

在类路径下没有找到log4j的配置文件

slf4j与jul、log4j1、log4j2、logback的集成原理

2016/08/29 20:03

发表了博客评论：

这里不是说每调用一次都自动归还，你既然都意识到这个问题了，那就肯定要优化下，比如放到ThreadLocal中。JdbcTemplate目前的实现是：如果开启了事务，则会用ThreadLocal进行暂存，如果没有开启事务，就是每次执行一次sql就释放连接到DataSource，可以详细研究下JdbcTemplate对连接的管理，这一块目前我也还有点疑问，一起讨论

Jedis的类型转换异常深究

2016/08/26 10:46

发表了博客评论：

是的，但是还有更多地方值得我们深思

1 jedis为什么要暴漏这么个危险的API给用户使用（即要求用户自觉的close，不自觉后果自负），
而这种增加用户操作复杂度的API是可以避免的，所以在我们开发相关框架给别人使用的时候，尽量避免出现这种情况。

2 可以再想想出现这种问题的根本原因是什么，即同步通信中的请求响应不匹配的问题，
这种应该是很容易出现的，给我们的启示就是：在一开始设计的时候就要去考虑这一点，从而就可以避免造出这么一个大坑

Jedis的类型转换异常深究

2016/08/25 10:12

发表了博客评论：

嗯，解决方式都差不多

Jedis的类型转换异常深究

2016/05/05 12:29

发表了博客评论：

文章开头就说了，2种模型都可以的。比如Netty就是你说的，就是第一种模型，Tomcat选择的是第二种模型。第一种模型每个连接只被一个Worker线程负责，就避免了并发问题，但会存在某个Worker线程很繁忙的时候，其他Worker线程却很空闲，效率没有第二种的高，第二种模型效率高但是会遇到多线程问题，在此问题上代码难度更大一些

tomcat的NIO线程模型源码分析

2015/10/27 09:46

发表了博客评论：

是的，就是依靠zk的。当服务器宕机，会导致服务器端在zk上注册的临时节点被自动删除，然后触发节点删除事件，推送该事件到客户端即订阅服务的一方，删除对应的Invoker，不会再发送请求给上述服务器。你所谓的实时，谁能做到呢？都是有一定延迟的，都还是比较短暂的，可以忍受就行

dubbo源码分析系列（4）dubbo通信设计

2015/10/26 12:24

发表了博客评论：

不错，都自己写RPC了

dubbo源码分析系列（4）dubbo通信设计

2015/10/20 19:58

发表了博客评论：

哪有，普通程序员而已