父子线程交互不当
真实业务场景中，通常会出现并发解决问题以充分利用CPU资源，为了防止过多的系统资源消耗在创建与销毁线程，我们一般会维系一个线程池。将任务委派给子线程去执行，最终主线程返回结果，这是web系统通常采用的手段。一些不成熟的做法就是主线程选择睡眠循环加不恰当的判断条件以等待子线程完成，这也是最终导致子线程处理行为与业务期盼结果不一致的主要原因，因为为开发人员往往误认为子线程应该做完任务，主线程可以返回了，但往往事与愿违。
我这样说可能比较抽象，举一个具体的例子把：
业务场景：dataQueue是一个blockingQueue，存放着我们需要的处理的任务，我们用线程池的方式去从dataQueue里面去任务，希望这些子线程将所有任务完成之后，主线程返回！
可这种操作方式会造成上述的错误，所以正确的做法如下：
这种方式主线程回阻塞到子线程全部完成才会返回，所以总结一下通常正确的做法分为4种：
1.Future，主线程遍历所有子线程Future.get(),直至全部取出，代表子线程全部完成，主线程方可返回。优点：写法优雅，缺点：假设子线程多到千万级别，JVM就要维系一个相当大的List,不合理
2.Countdownlatch，同步工具类，本质手段是沉睡，唤醒，计数器。优点:写法优雅，缺点:这种做法是要在一开始就确定该任务会委派给固定数量的子线程，如果业务变成去处理网络请求这类，并不会在一开始就知道我应该创建多少个子线程去解决该任务，这时候Countdownlatch自然巧妇难为无米之炊。
3.主线程直接获取线程池对象，循环判断getQueue().size()==0&&getActiveCount()==0加适当的睡眠时间，优点：万金油，缺点：写法不优雅
4.AtomicInteger，多个线程维系一个AtomicInteger变量，创建子线程任务的时候AtomicInteger加1，线程完成任务的时候减1，主线程只要循环及睡眠判断AtomicInteger==0即可。优点：AtomicInteger的加减都是基于CAS操作，同时也运用了volatile的线程可见性。缺点：写法不优雅
线程池不足之处
众所周知，线程池是由大师Doug Lea设计出来，替我们管理多个线程的生命周期，同时还提供了一个队列来实现线程池的弹性伸缩，具体可见其构造器多个参数的含义。我此处之所以提及线程池的不足并非为了沽名钓誉，鸡蛋里挑骨头，而是其基本的策略并不是完全能够满足所有的业务场景，所以我们需要在其基础之上做一点小小的改进，也就是学会“站在巨人肩膀上”。
在线程池的构造器参数当中
有这样的一个参数 RejectedExecutionHandler ，它会在线程池的线程数量达到maximumPoolSize，并且workQueue饱和之后，再有新的任务去调线程池的execute方法时候，就会去执行RejectedExecutionHandler 中的rejectedExecution方法。
rejectedExecution方法有很多实现类：
默认的是AbortPolicy ：处理程序遭到拒绝将抛出运行时 RejectedExecutionException。缺点：当我任务不想被丢弃时候，你给我丢弃了！
CallerRunsPolicy ：线程调用运行该任务的 execute 本身。这是什么意思呢，就是主线程直接去调用任务的run方法。缺点：这种方式确实不会丢弃任务，可是如果存在一种执行起来需要消耗很长时间的任务，你主线程因为线程池饱和所以决定用自己的线程去执行该任务，就在此时，线程池中的任务刚好全部完成，而且我的任务队列不大，所以接下来的一段时间，线程池就会线程闲置下来，而且主线程暂时没法去提交新的任务
DiscardPolicy ：丢弃被拒绝的任务。缺点：任务丢弃
DiscardOldestPolic： 如果执行程序尚未关闭，则位于工作队列头部的任务将被删除，然后重试执行程序（如果再次失败，则重复此过程）。缺点：任务丢弃
所以，基于这种情况，我们可以采取一种解决方案：
semaphore是Semaphore类的实例，此类也是大师Doug Lea设计，它的构造器也很简单就是就是传一个int类型的边界值，每来一个任务我们就acquire一个许可，执行完成就release一个许可。类似厕所有5个坑，假如有10个人要上厕所，那么同时只能有多少个人去上厕所呢？同时只能有5个人能够占用，当5个人中 的任何一个人让开后，其中等待的另外5个人中又有一个人可以占用了。另外等待的5个人中可以是随机获得优先机会，也可以是按照先来后到的顺序获得机会，这取决于构造Semaphore对象时传入的参数选项。
如此一来就解决了上述单一ThreadPoolExecutor的不足之处。
BlockQueue的使用意义
一提到BlockQueue，我们一般条件反射想到是的生产消费问题。可是我们为什么要提出生产消费模型？以前，我认为是生产速度和消费速度不一致，或者说不稳定，所以我们要建立一个缓冲区。这种解释是不错，但是还是过于书面化，因为解释的本身还是围绕的生产消费这对名词！
所以，我来了京东以后发现了更多技术背后的真正意义，需求！下面的例子就不赋上代码了，就直接口头解释了。比如说，我们组的业务就有一个需求，要从一个数据库中取出上千万条数据，然后针对里面的数据执行一条耗时很长的业务逻辑。所以现在摆在我们面前的问题有两点：1.数据太大，无法一次性加载到内存中。2.执行的业务逻辑处理一条数据耗时太长，与从数据库中取一条数据的耗时之短形成鲜明的对比。
基于这样的问题所在，我们想到了生产消费模型，采用了BlockingQueue。做法是这样的：既然数据很大，那我就分批读取，一次性读取1000条，然后丢到BlockingQueue作为生产者。消费者因为速度不及生产者快，所以采用线程池并行的从BlockingQueue中取。不再是非要将一个池子的水一次性装到一辆车上再送到用户那儿，更像是用管道从池子里面一次抽水送到用户那儿，颇有点pipeline的思想哈！
当然也真是因为这个我也增加了多多线程的理解，多线程难点在于一心多用，所以使用的难度不低，但我们还是要搞清楚多线程真正的应用场景，如果平白无故使用多线程，那么线程之间的切换或者阻塞和唤醒就会产生系统调度，增添了性能的消耗。所以多线程并非完美无瑕，那么我们为什么要采用多线程呢！
其实，动机也很单纯，就是让CPU忙起来。对于计算密集型任务，其实CPU使用率一直就很高，那么为什么还要多线程呢，那是因为目前我们的电脑是多核CPU，所以对于计算密集型任务，几核CPU创建几个线程是最理想的，多了就不好了，因为会因为线程切换而产生系统消耗。
可是，我们正常的业务中，并没有多少计算密集的任务，那么我们为啥还需要多线程呢？答案是IO。以我们组的项目为例，我不是说过我们会执行一个耗时很长的任务吗？时间的消耗主要是在IO上，IO就会导致你的线程被阻塞，CPU会闲置下来，所以我们引入多线程，来让我们的CPU忙起来！
Java同步器的理解
我个人理解的同步用下里巴人的解释方式就是多个线程为了达成某种步调一致的结果而采用的互斥方式，而互斥的主要表现在线程之间的等待与唤醒，当然了也不是全部这样，因为等待与唤醒是需要切换到内核态的，容易产生系统资源的消耗，所以CAS这种优秀的思想则经常拿来减少这样的弊端。
我来京东以前，一直认为同步就是synchronized为代表的锁住某个对象，以此来实现多个线程对同一个资源的访问，有序进行！后来才知道这样的理解是狭隘的。就比如说上述提及的Countdownlatch和Semaphore这两个同步器，它提出了一个共享锁的概念。什么是共享锁呢？首先它和数据库的共享锁概念有所不同，虽然名字相仿。共享就是多个线程可以去争夺某个资源（不被阻塞，可以运行下去的资格），而不是像synchronized一样，只让一个线程去执行，其余线程全部阻塞。
那共享锁是如何实现的呢？其实很简单，以Countdownlatch，Semaphore为例。其实他们底层都是用到了大师Doug Lea写的AQS（AbstractQueuedSynchronizer）这样的一个抽象类，它的内部会维护一个volatile类型的int变量state。当所有的线程想要去获得执行的资格的时候就会去访问这个state的变量，使用CAS操作将其减1，直至其变为0以后，后面的线程就会全部插入到一个名为CLH的队列当中（这里也涉及到一个公平队列和非公平队列，其实实现也就是一行代码的区别，相比于非公平策略，公平策略就是在后续来争抢资源的时候判断一下队列里面有没有被阻塞的线程，如果有，那就自将自己插入到队尾），并将自己阻塞。
他之所以采用双向链表外加head和tail两个额外的引用都是为了在并发的情况下使用CAS正确插入以实现无锁化，有兴趣的可以去看博客或者看源码，设计非常巧妙！
争抢共享锁，就必然存在释放共享锁以及唤醒被阻塞的线程们的过程。Countdownlatch和Semaphore看似不同，但是本质并无太大差异因为都是“共享模式”。对于Countdownlatch而言，线程们会陆续去调用countdown方法去将变量state依次减1，最后一个发现state变为0的线程就会去唤醒正在CLH队列中排队等待的线程，先唤醒排在最前面的那个线程。由于是共享模式，那个线程被唤醒后，自己检查state=0了，就结束阻塞，并且会通知下一个排队线程，下一个线程醒来后，一样判断state是否等于0了，然后结束阻塞，通知下一个，一直循环下去，直到所有阻塞中的线程全部被唤醒。
而Semaphore就是为了需求而去变法子玩转AQS而已，看过源码的同学会发现，底层函数都是一样的。那Semaphore究竟怎么玩的呢？之前获得共享锁的一些资源在流程执行完成之后会去执行释放资源，其实就是通过CAS给state加值，释放完成之后就会去AQS中唤醒被阻塞的线程，被唤醒的线程会再次去检查一下state以确定是否有资源可抢，就是用state减去他自己要消耗的n看是否不小于0，如果可以，就不再阻塞自己，同时由于共享模式，他会去唤醒队列中的下一个线程。以此类推，直至state被消耗成0。
由于时间有限，多数都是文字描述理念，后续会补上一些源码加上自己的注解以更加具体形象的表达思路。
这就是我的一些小总结，我还是那个观点，技术是为了解决问题而存在的，不是为了用技术而用技术。就像做题一样，做题时为了发现问题，然后带着问题去解决问题的。当然了，也不是不可以为了做题而做题，只是那样分数不见能考多高，哈哈！
