概述
线程安全是多线程编程时的计算机程序代码中的一个概念。在拥有共享数据的多条线程并行执行的程序中，线程安全的代码会通过同步机制保证各个线程都可以正常且正确的执行，不会出现数据污染等意外情况。
什么是线程安全？
多个线程访问同一个对象时，如果不用考虑这些线程在运行环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他操作，调用这个对象的行为都可以获得正确的结果，那么这个对象就是线程安全的。或者说，一个类或者程序所提供的接口对于线程来说是原子操作或者多个线程之间的切换不会导致该接口的执行结果存在二义性，也就是说我们不用考虑同步的问题。
线程安全问题的起因
线程安全问题都是由全局变量及静态变量引起的。若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时，执行写操作，一般都要考虑线程同步，否则就有可能影响线程安全。
如图1所示，这段代码在单线程或者串行的多线程情况下显然是线程安全的。如果在并行的多线程情况下，图1中的方法就会出现线程安全问题。笔者尝试开启了3条线程，并行访问图1中所示的方法，每个线程循环10次，得到了图2所示的结果：
可以看到，这里出现了两个26，然而根据代码逻辑，在运行正确的情况下根本不可能会得出这种结果，出现这种问题的根源就是线程安全问题。考虑以下情况：假设A线程在进入方法后，取得了变量count的值，并且还未能改变变量count的值，与此同时，B线程也进入方法，同样取得了变量count的值。此时，A线程与B线程取得的变量count的值完全相同，因此A线程和B线程执行方法体之后将会得出同样的结果，正如图2所示的出现两个26的情况。
如何保证线程安全？
当多个线程访问同一个方法时，无论这些如何交替执行，调用方都不需要做任何同步工作，其运行所得仍然是正确的结果，那么这个方法就是线程安全的。在图3所示的代码中，方法threadMethod()中并未出现全局变量或静态变量，毫无疑问，该方法是一个绝对线程安全的方法。
若在图3的方法中加入一个全局变量，如图4所示。
则此方法显然会出现线程安全问题，虽然单线程运行起来并不会出现任何问题，但是多线程并发访问此方法，全局变量count将会导致线程安全问题，如图5所示。
A线程和B线程进入这个方法后首先读取变量count的值，接着分别执行count++，修改变量count的值，此过程可视为分三步进行，即“读取->修改->赋值”。从图5中可以发现，变量count的值并非正确的结果。当A线程读取到count的值且并未修改时，B线程也读取到了count的值，此时count的值仍为1，正因如此，变量count的计算结果将会出现偏差。针对上述情况，Java中一般有两种方法来保证线程安全。
1.synchronized
关键字synchronized用来控制线程同步，确保多线程环境下，加上此关键字的方法不会被并行执行，如图6所示。
需要注意的是，关键字synchronized将会对非静态方法所属的对象进行加锁。当synchronized对一个对象进行加锁之后，其他线程必须等待正在访问此对象的线程执行完毕，释放锁之后才可以进行访问。
2.Lock
Lock是在Java1.6之后被引入进来，Lock与synchronized相比，前者的引入让锁有了更强的可操作性，即在实际使用过程中可以手动获取锁和释放锁，甚至还拥有中断获取以及超时获取的同步特性，但从使用便捷角度来看，Lock明显没有synchronized方便快捷，如图7所示。
进入方法首先需要获取锁对象，接着继续执行业务代码。与synchronized不同的是，Lock获取的锁对象需要手动释放，为了应对代码出现异常的情况，通常在finnally中执行释放锁的操作，因为finally的特性使得释放锁的操作必定会执行。
结语
在大型应用系统中，多线程的使用不可避免，此时线程安全问题就成为了亟需解决的问题，不考虑线程安全问题将会给整个系统埋下严重的安全隐患，只有在保证线程安全的前提下，应用系统才能正确稳定地运行。
