1、概述
2、线程安全
2.1、Java语言中的线程安全
按照线程安全的“安全程度”由强至弱来排序，我们可以将Java语言中各种操作共享的数据分为以下5类：不可变、绝对线程安全、相对线程安全、线程建荣和线程对立。
不可变
不可变的对象一定是线程安全的。
保证对象行为不影响自己状态的途径有很多种，其中最简单的就是把对象中带有状态的变量都声明为final。
Java API中符合不可变要求的类型：String，java.lang.Number的部分子类（如Long和Double的数值包装类，BigInteger和BigDecimal等大数据类型但`AtomicInteger`和`AtomicLong`则并非不可变的）。
绝对线程安全
Java API中标注自己是线程安全的类，大多数都不是绝对线程安全的。
相对线程安全
Java语言中，大部分的线程安全都属于这种类型，例如Vector，HashTable，Collections的synchronizedCollection()方法包装的集合等。
线程兼容
指通过使用同步手段来保证对象在并发环境中可以安全的使用。Java API中大部分的类都是属于线程兼容的，如ArrayList和HashMap。
线程对立
指无论调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码。
一个线程对立的例子就是Thread类的suspend()和resumn()方法（已被JDK声明废弃了）。
常见的线程对立操作还有System.setIn(), System.setOut(), System.runFinalizersOnExit()...
2.2、线程安全的实现方法
互斥同步
Java中，最基本的互斥同步手段就是synchronized关键字。
synchronized是一个重量级的操作，因为：Java的线程是映射到操作系统的原生线程之上的，如果要阻塞或唤醒一个线程，都需要操作系统来帮忙完成，这就需要从用户态转换到核心态中，因此状态转换需要消耗很多的处理器时间。对于代码简单的同步块（如synchronized修饰的getter()和setter方法），状态转换消耗的时间有可能比用户代码执行的时间还要长。
还可以使用java.util.concurrent包中的`ReentrantLock(重入锁)`来实现同步：JDK1.5多线程环境下synchronized的吞吐量下降的很严重，而ReentrantLock则基本保持在同一个比较稳定的水平上。JDK 1.6之后两者性能基本持平。
虚拟机在未来的性能改进中还会更偏向于原生的synchronize的，所以还是
提倡在synchronized能实现需求的情况下，优先考虑使用synchronized来进行同步。
非阻塞同步
非阻塞同步：从处理问题的方式上说，互斥同步属于一种悲观的并发策略。随着硬件指令集的发展，我们可以采用基于冲突检查的乐观并发策略，通俗地说，就是先行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采取其他的补偿措施（最常见的补偿措施就是不断地重试，直到成功为止），这种乐观的并发策略的许多实现偶读不需要把线程挂起，因此这话总同步操作称为非阻塞同步。
无同步方案
如果一个方法本来就不设计共享数据，那它自然就无须任何同步措施去保证正确性，因此会有一些代码天生就是线程安全的。这类代码包括：可重入代码和线程本地存储。
3、锁优化
为了进一步改进高效并发，HotSpot虚拟机开发团队在JDK1.6版本上花费了大量精力实现各种锁优化。
##3.1、自旋锁与自适应自旋
为了让线程等待，我们只需要让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。引入自旋锁的原因是互斥同步对性能最大的影响是阻塞的实现，管钱线程和恢复线程的操作都需要转入内核态中完成，给并发带来很大压力。自旋锁让物理机器有一个以上的处理器的时候，能让两个或以上的线程同时并行执行。
3.2、锁消除
消除锁是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。
3.3、锁粗化
如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，则可以进行锁粗化的优化。
3.4、轻量级锁
它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
但是如果存在锁竞争，除了互斥量的开销，还发生了CAS操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。
3.5、偏向锁
如果说轻量级锁是在无竞争的情况下使用了CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉了，连CAS操作都不做了。
4、本章小结
