线程安全
当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象就是线程安全的。
Java语言中的线程安全
讨论线程安全，就限定于多个线程之间存在共享数据访问这个前提，因为如果一段代码根本不会与其他线程共享数据，那么从线程安全的角度来看，程序是串行执行还是多线程执行对它来说是完全没有区别的。我们将Java语言中各种操作共享的数据分为以下5类：不可变、绝对线程安全、相对线程安全、线程兼容和线程独立。
- 不可变
在Java语言中，不可变的对象一定是线程安全的。基本数据类型采用final关键字修饰，如果是对象则需要保证自己的行为不会影响状态，例如String的replace()等方法都是产生新的对象。 - 绝对线程安全
绝对的线程安全就是前面的提到的定义，这个定义很严格，一个类要达到「不管运行时环境如何，调用者都不需要任何额外的同步措施」通常需要付出很大的，甚至有时候是不切实际的代价。在Java API中标注自己是线程安全的类，大多数都不是绝对的线程安全。 - 相对线程安全
相对的线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单独的操作是线程安全的，我们在调用的时候不需要做额外保障措施。在Java语言中，大部分的线程安全类都属于这种类型，例如Vector、HashTable等。 - 线程兼容
线程兼容是指对象本身并不是线程安全的，但是可以通过调用端正确地使用同步手段来保证对象在并发环境中可以安全的使用，我们平常说一个类不是线程安全的，绝大多数时候指的是这一种情况。 - 线程对立
线程对立是指无论调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码。一个线程对立的例子是Thread类的suspend()和resume()方法，如果并发进行的话，无论调用时是否进行了同步，目标线程都是存在死锁风险的，如果suspend()中断的线程就是即将要执行resume()的那个线程，那肯定就要产生死锁了。
线程安全的实现方法
互斥同步
互斥同步（Mutual Exclusion & Synchronization）是常见的一种并发正确性保证手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一时刻只能被一个（或者是一些，使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区（Critial Section）、互斥量（Mutex）和信号量（Semaphore）都是主要的互斥实现方式。因此，在这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的。
在Java中，最基本的互斥同步手段就是synchronized关键字，synchronized关键字在经过编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令。
根据虚拟机规范的要求，在执行monitorenter指令时，首先要尝试获取对象的锁，如果这个对象没有被锁定，或者当前线程已经拥有了那个对象的锁，把锁的计数器加1，相应的，在执行monitorexit指令时会将锁计数器减1，当计数器为0时，锁就被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另外一个线程释放为止。
关于monitorenter和monitorexit，有两点是要特别注意的：synchronized同步块对同一条线程来说是可重入的，不会出现把自己锁死的问题
同步块在已进入的线程执行完之前，会阻塞后面其它线程的进入
因为Java的线程是映射到操作系统的原生线程之上的，如果要阻塞或者唤醒一个线程，都需要操作系统来帮忙完成，这就需要从用户态转换到核心态中，因此状态转换需要耗费很多的处理器时间，对于代码简单的同步块，状态转换消耗的时间有可能比用户代码执行的时间还长，所以synchronized是Java语言中一个重量级（Heavyweight）锁，有经验的程序员都会在确实必要的情况下才使用这种操作。
除了synchronized，还有java.util.concurrent包中的ReentrantLock来实现同步。
非阻塞同步
互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步。互斥同步属于一种悲观的并发策略。随着硬件指令集（CAS指令）的发展，我们还可以采用基于冲突检测的乐观并发策略：先操作，没有其他线程竞争，就成功了；如果有其他线程争用，产生了冲突，就再采取补偿措施。
AtomicInteger的incrementAndGet方法就是无限循环自增直到成功。
锁优化
自旋锁与自适应自旋
互斥同步，对性能影响最大的是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核状态完成，这些操作给系统的并发性能带来了很大的压力。同时，虚拟机开发团队也注意到很多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。如果物理机上有一个以上的处理器，能让两个或两个以上的线程同时并行执行，我们就可以让后面请求锁的那个线程”稍等一下”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只需要让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。
JDK1.4.2就已经引入了自旋锁，只不过默认是关闭的，在JDK1.6中就已经改为默认开启了。自旋不能代替阻塞，且先不说处理器数量的要求，自旋等待本身虽然避免了线程切换的开销，但是它是要占据处理器时间的，因此如果锁被占用的时间很短，自旋等待的效果就非常好；反之，如果锁被占用的时间很长，那么自旋的线程只会白白消耗处理器资源，而不会做任何有用的工作，反而会带来性能上的浪费。因此自旋等待必须有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程了，自旋次数的默认值是10，可以使用参数-XX:PreBlockSpin来更改。
在JDK1.6之后引入了自适应的自旋锁。自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上自旋的时间以及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间，比如100个循环。另外如果对于某一个锁，自旋很少成功获得过，那么在以后要获得这个锁时将可能忽略掉自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越准确。
锁消除
锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的支持，如果判断在一段代码中，堆上所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然无需进行。
锁粗化
原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小—-只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快拿到锁。
大部分情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。