Java内存模型的主要目标是定义程序中的各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量跟java编程中的变量有一定的区别，它包括实例字段、静态字段和构成数组对象的元素，但不包括局部变量与方法参数，因为后者是线程私有的，不会被共享，自然不存在竞争问题。
钟无艳
我的博客终究是为自己而写的，为了避免让身边的朋友看到而产生略微的尴尬，我索性都把这类记叙文章的日期改在了一年前。
我记得以前在大学的时候跟初恋女友在田径场散步的时候，经常会扯一些道理，不过往往我总是那个道理输出者，而女友总是在一旁安静的听着，听到共鸣处，她猛然抬头，对我赞不绝口，那种崇拜与惊喜之情仿佛是要从女友眼睛里面溢出来一样。
深入理解JVM之JIT编译器（二）
上篇是分析了一下前段编译器，主要过程完成从java代码到字节码的转变，它的改进顶多是提高程序的编码速度和效率。本篇尝试探索JIT编译器，它能够完成从字节码到本地机器码的转变，从而真正的影响程序的运行效率。
深入理解JVM之前端编译器（一）
前两天在leetcode做了算法题，惊讶的发现用java实现的时间复杂度，竟然跻身于C/C++同列，甚至偶尔会超过后两者，虽然知道JVM功不可没，但还是很好奇在VM编译过程中到底发生了什么，翻出《深入理解java虚拟机》一探究竟，算是有所收获，记录如下。
Raft算法笔记之安全性（四）
前面的章节里描述了 Raft 算法是如何选举和复制日志的。然而，到目前为止描述的机制并不能充分的保证每一个状态机会按照相同的顺序执行相同的指令。例如，一个跟随者可能会进入不可用状态同时领导人已经提交了若干的日志条目，然后这个跟随者可能会被选举为领导人并且覆盖这些日志条目；因此，不同的状态机可能会执行不同的指令序列。
这一节通过在领导选举的时候增加一些限制来完善了 Raft 算法。这一限制保证了任何的领导人对于给定的任期号，都拥有了之前任期的所有被提交的日志条目。增加这一选举时的限制，我们对于提交时的规则也更加清晰。最终，我们展示对于领导人完整特性的简要证明并且说明领导人是如何领导复制状态机的正确行为的。
Raft算法笔记之日志复制（三）
Raft算法的日志复制是基于领导人的，如果不清楚领导人选举机制可以阅读上一篇领导人选举。
Raft算法笔记之领导人选举（二）
Raft算法作者在设计算法过程中为了提升算法可理解性，决定将算法分解为三个模块，分别是领导人选举、日志复制和安全性证明。这种将一个大问题分解成小问题的思路还是不错的，所以我姑且将一篇大论文分成几篇小博文来单独分析，希望能得作者心法真传。本篇主要内容是领导人选举。
Raft算法笔记（一）
之前记得微博上有个博主在关于知乎上讨论「精通C++语言是一种怎样的体验」的时候，评论了一句，印象很深刻，刚刚翻出来有看了一下，原话是：“建议青年学子多把时间花在基础理论「算法，操作系统，编译原理」和具体领域「数据库，分布式系统，并发编程，机器学习」”，私以为是有几分道理的，然后最近不知怎么就对分布式感兴趣起来了。技术学习无止境，但是保持好奇心和敏锐度，总是需要的。
本文是浓缩版（虽然我觉得原论文写得更好，没有一句废话），主要是记录在阅读Raft算法过程中的理解和笔记，方便日后回头温习，如果感兴趣并且条件允许可以阅读论文原文和论文中文翻译，见文末参考资料。
Docker安装与启动
背景
第一次听到docker这个词是15年7月份，老板让项目组老大看看docker相关技术，据说是可以提高公司项目部署的效率，不过遗憾的是的当时已经准备快离职了，所以没能早一点一睹docker容器的庐山真面目。现在看来docker的热度也不是一年之前能比的了，不过也激发了我对技术的好奇心，决定挖这样一个坑，来激励自己去研究一下docker的内部原理和实际应用。本篇文章记录安装过程中出现的一些问题和解决过程，重点在于启动过程中的几个错误。
注：不同的系统和硬件环境下安装文件和过程不太一样，所以:
- 采用Docker Toolbox方式安装的请绕行。
- 以下适用于Docker for Windows Beta的安装，详情请看下面「安装-环境要求」。
Tomcat源码分析之Connector初始化与启动
Tomcat主要由两大核心组件，一个是connector,一个是container。connector负责的是底层的网络通信的实现，而container负责的是上层servlet业务的实现。一个应用服务器的性能很大程度上取决于网络通信模块的实现，因此connector对于tomcat而言是重中之重。源码看到Connector的时候，确实看的比较费劲，里面错综复杂的类结构和继承关系，确实头昏脑涨，下面我尝试用清晰一点的脉络去理解Connector。