线程小感

1. 线程池执行线程任务的步骤：
   1) 调用Executors类的静态工厂方法创建一个ExecutorService对象，该对象代表一个线程池；
   2) 创建Runnable实现类或Callable实现类的实例，作为线程执行任务；
   3) 调用ExecutorServer对象的submit方法提交Runnable实例或Callable实例；
   4) 当不再提交任何任务时，调用ExecutorService对象的Shutdown方法来关闭线程池。
2. Java8新增的线程池方法：
   1) ExecutorService newWorkStealingPool(int parallelist):创建持有足够线程的线程池来支持给定的并行级别，该方法还会使用多个队列来减少竞争；
   2) ExecutorService newWorkStealingPool():该方法可以看做是前一个方法的简本，并行级别不需要用户手工指定，是根据计算机CPU个数自动生成的，如果当前机器有6个CPU，则调用该方法时并行级别被设为6。
   Java8在线程支持上增加了利用多CPU并行的能力，以更好地发挥底层硬件的性能，这两个方法生成的work stealing池，都相当于后台线程池，如果所有的前台线程都死亡了，work stealig池中的线程也会自动死亡。
3. Java8扩展的ForkJoinPool功能：
   Java8除了继续支持早期版本中的ForkJoinPoll(int parallelism)和ForkJoinPoll()两个方法外，还扩展了ForkJoinPoll的功能，增加了下面两个方法：
   1) ForkJoinPoll commonPool()：该方法返回一个通用池，通用池的运行状态不受shutDown()或shutdownNow()方法的影响。但如果程序直接调用System.exit(0)来终止虚拟机，通用池以及通用池中正在执行的任务都会被自动终止；
   2) int getCommonPollParallelism()：该方法返回通用池的并行级别。
4. 线程安全工具类ThreadLocal和同步机制的区别：
   ThreadLocal是将需要并发访问的对象复制多份，每个线程拥有独立的一份资源，在编写多线程代码时，可以将不安全的整个变量封装进ThreaLocal，或者将与访问对象相关的状态使用ThreadLocal保存，用以保证安全。
   同步机制是通过对象加锁来实现多个线程对同一变量的访问安全的，该变量为多个线程共享，需要我们分析什么时候对变量进行读写，什么时候需要锁定对象，什么时候释放对该对象的加锁等。在这个过程中，程序并没有将资源(变量)复制多份，只是采用了安全机制来控制对这份资源的访问。
   ThreadLocal不能替代同步机制，两者所对应的解决方案不同。同步机制是为了同步多个线程对相同资源的访问，是多个线程之间进行通信的方式，而ThreadLocal是为了隔离多个线程的数据共享，从根本上避免多个线程之间对共享资源的竞争。
5. Map对象线程安全和同步：
   昨天的日报提到了网页即时聊天信息保存在Map对象中，如何保证线程安全。下面讲几种实现方式，有理解的不对的地方，恳请各位师兄批评指正：
   1) 对非线程安全的HashMap对象加锁，采用采用Copy On Write机制：
   当我们读取Map的时候，直接读取，不需要同步。当我们修改数据的时候，我们就把当前数据Copy一份副本，然后在这个副本上进行修改，完成之后，再用修改后的副本，替换掉原来的数据，修改过程应该加锁，用来保证数据一致，关键代码如下：

这种方式虽然可以保证线程安全和数据一致，读的效率不受影响，但写的效率太低，适合用于高频率读低频率写的场景。
2) 线程安全的HashTable对象：
HashTable可以说是多线程环境下的HashMap，它除了线程安全这个特性之外，其余特点几乎与HashMap一样，所以高版本（>JDK1.5）的Java中一般不选择使用HashTable这话中数据类型。
3) 线程安全的ConcurrentHashMap对象：
之所以多线程环境下选择使用ConcurrentHashMap而不选择HashTable的原因是，线程对HashTable的加锁是独占式的，即同时只允许一个线程对HashTable加写锁，写的效率大大降低，而ConcurrentHashMap的加锁机制有别于HashTable：
ConcurrentHashMap将hash表分为16个桶（默认值），诸如put,remove等常用写操作只锁当前需要用到的桶，原来只能一个线程进入，现在能同时有16个写线程进入（写线程才需要锁定，而读线程几乎不受限制），相对于HashTable而言，ConcurrentHashMap并发性的提升是显而易见的。
所以，昨天提到的问题就可以用ConcurrentHashMap来完美解决，既能保证写效率的提升，又不影响读取效率。