据我理解，那个定时任务，会从hive里拿出超多的数据（据说2亿左右），按具体业务做数据整合和处理，最终推送到es（elasticsearch）中。（hive什么的我没搞过，但不妨碍要讨论的东西）

上篇文章 AQS系列一：源码分析非公平ReentrantLock 中，我们分析了ReentrantLock的非公平实现，本篇会承接上文，继续分析ReentrantLock的公平锁实现（以及Condition的实现）。

早些时候（jdk 1.5之前），并发环境下做同步控制，你的选择不多，多半是使用synchronized关键字。不管是同步方法还是同步块，总之遇到这个关键字，未获取锁线程就会乖乖等候，直到已获取锁的线程释放掉锁。

可是，身处jdk1.4（甚至更早）的前辈们，要怎么做才能拿到线程返回值呢？或者说，禁用Callable技能，怎么获取线程返回值？嗯，这似乎是线程间通信的问题；只有Runnable作为武器，有些麻烦，接受挑战！

如果你看过设计模式，肯定会知道单例模式，实际上这是我能默写出代码的第一个设计模式，虽然很长一段时间我并不清楚单例具体是做什么用的。这里简单提一下单例的用处。作为java程序员，你应该知道spring框架，而其中最核心的IOC，在默认情况下注入的Bean就是单例的。有什么好处？那些Service、Dao等只创建一次，不必每次...

jdk1.8中的hashmap作了很多改进：红黑树的引入，链表尾插，以及底层数组长度保持2的次幂。本文专注于分析2次幂设定的原因，且听我慢慢道来……

最近盯上了java collection框架中一个类——ArrayDeque。很多人可能没用过甚至没听说过这个类（i'm sorry,what's fu*k this?），毕竟你坐在面试官面前的时候，关于数组链表的掌握情况，99%的可能性听到问题会是：说说ArrayList和LinkedList的区别？今天从ArrayDeque入手，换一个角度来检验下我们是否真正掌握了数组、链表。

最近研究算法，遇到的一道很有意思的问题——怎么把一个链表反转？很容易想到一个方法：遍历链表，数组作栈存储路径，元素逐个出栈得到的就是反转后的链表！查找资料发现，有更好的方式实现。

事情时这样的：在搞懂简单二叉树的过程中，经常需要验证自己的代码有没有问题，我之前的做法是“断点+肉眼观察”大法。随着节点的增多，断点还好，肉眼越来越扛不住，遂决定把树打印出来。把树的各种操作（新增/删除节点）前后进行比对，是非一目了然！

继线性结构之后，人们之所以又发明了树形结构，是为了方便查找。普通树随便生长，看着就眼晕，除了和自然界的树结构相似对得起Tree这名号，没太大价值，更别提方便查找了。

我们对15个10以内（0-10）的数字按从小到大的顺序进行排序，比如source = [6, 8, 6, 2, 2, 10, 8, 5, 1, 9, 6, 4, 0, 2, 7]，计数排序是这么运作的。

a、b、c、d、e、f、g是七个城镇，它们之间的连线表示汽车行驶路线，而连线上的箭头表示道路允许方向。（比如，a和c之间，箭头由a指向c，表示可以开车从a行驶到c；反之，从c直接行驶到a是不行的）问题，找出一条从A镇到G镇途径镇子最少的路线。

我们要在数组中查找一个值，比如红框圈中的 元素5 ，可以通过遍历或者排序后二分的方式达到目的。没有更快捷的查找方式了吗？显然是有的，比如Map。我们对存 / 取动一动脑筋，还是上图的那些元素，假如我们这样存：

分治 快速排序（以下简称“快排”）的核心思想是分治法。可以说，分治提供了另一种解决问题的思路。举个例子来进行说明，抓稳扶好，直接开车了…… 举例 现有一个集合{4,8,2,5,7,-1,3}，我们将对它进行从小到大排序： 1.选取第一个元素4作为基准值，后面的元素逐个和这个基准值比较大小 显然，要么大于，要么小于（ 暂不考虑...

序 大概半个月前，偶尔看到《算法图解》，没翻几页便被数学战五渣的我奉为神书，怎一个相见恨晚、爱不释手加老泪纵横啊！遂写文以作积累…… 选择排序 思路 选择排序的思路很好理解，以从小到大排序为例： 选出集合中最小的元素，置于目标集合第一个位置 重复上述过程，剩余元素中选出最小的元素，置于目标集合第二个位置…...

一周时间的Channel家族学习，一度让我怀疑人生——研究这个方法有没有用？学习Netty是不是有点儿下了高速走乡间小路的意思？我为啥要读源码？之所以产生这些疑问，除了我本身心理活动丰富以外，主要病因在于没搞清楚Channel在Netty体系中的定位。而没能清晰理解Netty的定位，也默默的送出了一记助攻。

卡车指的是java原生类ByteBuffer，这兄弟在NIO界大名鼎鼎，与Channel、Selector的铁三角组合构筑了NIO的核心。之所以称它为卡车，只因《编程思想》中有段比喻：

之前的两篇文章 FastThreadLocal怎么Fast？、ScheduledThreadPoolExecutor源码解读 搞的我心力交瘁，且读源码过程中深感功力不足，遂决定“磨刀”——先达到较熟练使用netty的程度，再回过头来继续啃源码！至于“磨刀石”嘛，选择了《Netty权威指南》（第二版）……哎呦，不错奥！

scheduleAtFixedRate也是该类常用的打开方式之一，网上很多文章会拿该方法与scheduleWithFixedDelay进行对比，对比结果其实和方法名一致：

FastThreadLocal的类名本身就充满了对ThreadLocal的挑衅，“快男”FastThreadLocal是怎么快的？源码中类注释坦白如下：

阅读源码时，发现很多System.getProperty("xxx")，理所当然会想：what's fucking this? 翻阅资料后，Get该技能，姿势如下： 环境中的全部属性 System.getProperties() {代码...} 代码中定义属性 System.setProperty("xxx") {代码...} 启动参数指定 -Dkey=val {代码...}

ServiceLoader直译为服务加载器，最终目的是获取service的impl实现类。正如前文所说，它将加载META-INF/services下的配置文件，来锁定impl实现类。