同步容器，如HashTable，提供独占访问。
并发容器，ConcurrentHashMap，有着更好的并发性能，但是不能独占访问。
--putIfAbsent
同步工具：
闭锁：CountDownLatch
FutureTask
Semaphore
栅栏：Barrier
Executor框架：
Executors.newFixedThreadPool()
Executors.newCachedThreadPool()
ExecutorService接口，获取Future运行结果。
CompletionService接口，ExecutorCompletionService，并行运行，并等待结果。
...等
java并没有提供某种抢占式的机制来取消操作或者终结内存，它提供了一种协作式的中断机制来实现取消操作。
当有界队列被填满后，饱和策略开始发挥作用。
--终止策略，抛弃任务，并抛出未受检异常
--调用者运行策略。
--对策略进行修改。
线程工厂ThreadFactory。自定义线程工厂，为新线程指定UncaughtExceptionHandler、定制Thread类用于记录信息等。
定制和扩展ThreadPoolExcutor。
--定制：自定义线程池大小、存活时间、线程工厂、饱和策略等。
--扩展：beforeExecute(),afterExecute和terminate()。可以添加计时、日志、统计和信息收集功能。
stream并行处理，CompletableFuture
关闭和取消：
1. 如何好的关闭一个任务？
任务和线程是独立的，也就是说线程运行任务，但是关闭任务并不意味着退出线程。
a）stop()函数----@Deprecated。已经弃用，因为强制退出线程，会造成很多无法预料的错误。
* @deprecated This method is inherently unsafe. Stopping a thread with * Thread.stop causes it to unlock all of the monitors that it * has locked (as a natural consequence of the unchecked * <code>ThreadDeath</code> exception propagating up the stack). If * any of the objects previously protected by these monitors were in * an inconsistent state, the damaged objects become visible to * other threads, potentially resulting in arbitrary behavior. Many * uses of <code>stop</code> should be replaced by code that simply * modifies some variable to indicate that the target thread should * stop running. The target thread should check this variable * regularly, and return from its run method in an orderly fashion * if the variable indicates that it is to stop running. If the * target thread waits for long periods (on a condition variable, * for example), the <code>interrupt</code> method should be used to * interrupt the wait.
b）使用共享变量。
在遇到阻塞等待时，就失去效果了。
https://stackoverflow.com/questions/10961714/how-to-properly-stop-the-thread-in-java
c）使用中断。
需要任务代码的支持，只能解决抛出InterruptedException异常的阻塞，如果任务代码不支持或者如IO阻塞等，也失去了效果。
d）处理不可中断的阻塞。
自己实现Thread的继承类，重写interrupt()函数，自行关闭阻塞的函数，如关闭IO连接等。
http://www.cnblogs.com/simbachen/p/4009562.html
总结：如果写多线程程序时，需要考虑提前结束的情况，那么要有任务代码的支持。任务代码必须要考虑如何响应中断，如何提前关闭，而不是只考虑计算逻辑等待线程被强制结束。
因为强制结束会有很多不确定因素，比如可能部分修改了对象中的变量，标志位没有恢复，IO未关闭等。
ps. 对继承的认识有了提高，以前觉得继承只是为了继承一些属性和行为，现在发现可以做的事情很多，可以扩展行为，可以改变行为。
处理非正常的线程终止：捕获RuntimeException。
未捕获异常的处理：继承UncaughtExceptionHandler，有点像spring中的ExceptionHandler；ThreadGroup。
钩子：通过Runtime.getRuntime().addShutdownHook()注册。当jvm关闭的时候，会执行系统中已经设置的所有通过方法addShutdownHook添加的钩子，当系统执行完这些钩子后，jvm才会关闭。所以这些钩子可以在jvm关闭的时候进行内存清理、对象销毁等操作。
同一个JVM最好只使用一个关闭钩子，而不是每个服务都使用一个不同的关闭钩子，使用多个关闭钩子可能会出现当前这个钩子所要依赖的服务可能已经被另外一个关闭钩子关闭了。为了避免这种情况，建议关闭操作在单个线程中串行执行，从而避免了再关闭操作之间出现竞态条件或者死锁等问题。
http://www.cnblogs.com/zhuawang/p/4523503.html
守护线程，非守护线程：
考虑多线程的代价。
1. 死锁
2. 性能。上下文切换，内存同步，阻塞。
3. 锁的竞争。锁分段，锁分解。
测试多线程。
1. 贴近真实场景
2. 线程执行的不确定性。
3. 使用 回调函数 或者 扩展类 获取信息。
4. 考虑垃圾回收、动态编译/编译优化的影响。
ReentrantLock、ReadWriteLock和synchronized内置锁
1. ReentrantLock实现Lock接口，更丰富，提供定时的锁等待、可中断的锁等待、公平性选择。但是是互斥的。
2. synchronized编写简单，出代码块时自动unlock。
3. 读写锁ReadWriteLock。可选读优先/写优先，多个读一个写。
java更底层的同步机制
synchronized和wait/notify/notifyAll结合使用，注意“过早唤醒”和“信号丢失”情况。
Condition，更细分等待线程。
悲观锁--独占性，lock
乐观锁--CAS（会有ABA问题）
安全的发布/不安全的发布：缺少happens-before关系时，会出现重排序现象。
