目录
•写在前面
进程想要执行任务需要依赖线程，换句话说就是进程中的最小执行单位就是线程，并且一个进程中至少有一个线程。提到多线程这里要说两个概念，就是串行和并行，搞清楚这个我们才能更好的理解多线程。所谓串行其实是相对于单条线程来执行多个任务来说的，我们就拿下载文件来举个例子，我们下载多个文件，在串行中它是按照一定的顺序去进行下载的，也就是说必须等下载完A之后，才能开始下载B，它们在时间上是不可能发生重叠的。
要编写线程安全的代码，其核心在于要对状态访问操作进行管理，特别是对共享的和可变的状态的访问。要是的对象是线程安全的，需要采用同步机制来协同对对象可变状态的访问，如果无法实现协同，那么可能会导致数据破坏以及其他不该出现的结果。java中的同步机制是关键字synchronized，它提供了独占式的加锁方式，不仅如此还包括volatile类型变量，显式锁Lock以及原子变量。
单线程近似定义为“所见即所知”，那么定义线程安全性，则当多个线程访问某个类时，这个类始终都能表现出正确的行为，那么就称这个类是线程安全的。一个类在单线程中运行都不正确，那么它肯定是不会是线程安全的。如果正确的实现了某个对象，那么在任何操作中（包括调用对象的公有方法或者对其公有域进行读写操作）都不会违背不变性条件或后验条件。在线程安全类的对象实例上执行的任何串行或并行操作都不会处于无效状态。
无状态的对象一定是安全的，啥是无状态？这个类既不包括任何域，也不包括任何对其他类中域的引用。举个例子，大多数Servlet都是无状态的，从而极大的降低了在实现Servlet线程安全性时的复杂性，只有当Servlet在处理请求时需要保存一些信息，线程安全性才会成为一个问题。
•原子性
其实原子性就是一个不可分割的，我们怎么理解呢？举个例子，当我们在无状态对象中增加一个状态时，会发生什么情况？比我们要计算一个类调用了多少次（这个类可以是Servlet），我们定义一个私有的Long类型的域（命名为count），在方法中没调用一次就将这个值加一（即count++），如下。
Integer count = 0;
public void getCount() {
count ++;
System.out.println(count);
}由于我们没有对这个类进行任何的同步机制操作，所以这个类是非线程安全的，虽然在单线程环境中能正确运行，但在多线程情况下就会出现问题。我们注意到count++这个操作，这个操作看上去是一个操作，其实这个操作并非原子性的，因为它并不会作为一个不可分割的操作来执行，实际上count++ 包含了三个独立的操作，分为读取count的值，将值加1，然后计算结构写入count中，这是一个“读取-修改-写入”的操作序列，并且其结果依赖于之前的状态。在并发下就会出现问题，我再多线程下跑了上面那段代码，结果如下
我们可以看到，这里出现了两个26，为什么会出现这种情况，出现这种情况显然表明我们这个方法根本就不是线程安全的，出现这种问题的原因有很多，我们说最常见的一种，就是我们A线程在进入方法后，拿到了count的值，刚把这个值读取出来还没有改变count的值的时候，结果线程B也进来的，那么导致线程A和线程B拿到的count值是一样的。
在并发编程中，这种由于不恰当的执行时序而出现不正确的结果是一种非常重要的情况，它有一个正式的名字，叫“竞态条件”。竞态条件是啥？当某个计算的正确性取决于多个线程的交替执行时序时，那么就会发生竞态条件，最常见的竞态条件类型就是“先检查后执行”操作，即通过一个可能失效的观察结果来决定下一步的动作。比如首先观察到某个条件为真（例如文件X不存在），然后根据这个观察结果采用相应的动作（创建文件X），但事实上，在你观察到这个结果以及开始创建文件之间，观察结果可能变得无效（另一个线程在这个期间创建了文件X），从而导致各种问题（未预期的异常、数据覆盖、文件被破坏等）。
与大多数并发错误一样，竞态条件并不总是会产生错误，还需要某种不恰当的执行时序。原子操作是对于访问同一个状态的所有操作（包括该操作本身）来说，这个操作是一个以原子方式执行的操作。而我们前面提到的类似count++的这种操作，叫做复合操作，即包含了一组必须以原子方式执行的操作以确保线程安全性。在实际情况中，应该尽可能的使用现有的线程安全对象来管理类的状态，与非线程安全的对象相比，判断线程安全对象的可能状态及其状态转换情况要更为容易，从而也更容易维护和验证线程安全性。这里值得一提的是，java中给我们弄好了很多原子操作的类型，在这个包下java.util.concurrent.atomic。
加锁机制
上面我们说了，我们可以对单个类进行原子性操作，这样可以保证我们程序的安全性，但是，我们想一想，如果当多个原子性的操作同时进行时，而且各个原子性操作之间都存在相互依赖的关系，这种情况下，我们怎么保证程序运行正确（线程安全）？如果还是使用原子性操作的方法，那么我们要保持状态的一致性，就需要在单个原子操作中更新所有相关的状态变量。
说到这里，我们就不得不提一下java提供的一种内置的锁机制来支持原子性，即同步代码块（synchronized block），同步代码快包括两部分，一个作为锁的对象引用，一个作为由这个锁保护的代码块。以关键字synchronized来修饰的方法就是一种横跨整个方法体的同步代码块，其中该同步代码块的锁就是方法调用所在的对象。每个Java对象都可以用作一个实现同步的锁，这些所被称为内置锁或监视器锁。线程在进入同步代码块之前会自动获得锁，并且在退出同步代码块时自动释放锁，这里要说，获得内置锁的唯一途径就是进入由这个锁保护的同步代码块或方法。值得一提的是，内置锁相当于一种互斥锁，意味着最多只有一个线程能持有这种锁。要注意了，任何一个执行同步代码块的线程，都不能看到有其他线程正在执行由同一锁保护的同步代码块（这里涉及到可见性的问题）。synchronized直接加在方法上，虽然能很方便的解决线程安全的问题，但是也会带来性能低下的问题，所以synchronized怎么使用，也是值得学习的。
可重入函数可以由多于一个任务并发使用，而不必担心数据错误。相反，不可重入函数不能由超过一个任务所共享，除非能确保函数的互斥（或者使用信号量，或者在代码的关键部分禁用中断）。可重入函数可以在任意时刻被中断，稍后再继续运行，不会丢失数据。可重入函数要么使用本地变量，要么在使用全局变量时保护自己的数据。
当某个线程请求一个由其他线程持有的锁时，发出请求的线程就会被阻塞，然而，由于内置锁是可重入的，因此如果某个线程试图获得一个已经由它自己持有的锁，那么这个请求就会成功。“重入”意味着获取锁的操作的粒度是线程，而不是调用。重入的一种实现方式是，为每一个锁关联一个获取计数值和一个所有者线程，当计数值为0时，这个锁就被认为是没有被任何线程持有。当线程请求一个未被持有的锁时，JVM将记下锁的持有者，并且将获取计数值置为1，如果同一个线程再次请求获取这个锁，计数值将递增，而当线程退出同步代码块时，计数器会相应的递减，当计数值为0时，这个锁将被释放。
到此我们就可以将多个复合操作封装到一个同步代码块中，但是这样是不够的，如果用同步代码块来协调对某个变量的访问，那么在访问这个变量的所有位置上都需要使用同步。而且，当使用锁来协调对某个变量的访问是，在访问变量的所有位置上都要使用同一个锁。而且，并不是只有在写入共享变量时才需要使用同步，对于可能被多个线程同时访问的可变状态变量，在访问它时都需要有同一个锁，这种情况下，我们成状态变量时由这个锁保护的。
在这里值得一提的是，当使用锁时，你应该清楚代码块中实现的功能，以及在执行该代码块时是否需要很长的时间。无论是执行计算密集的操作，还是在执行某个可能阻塞的操作，如果持有锁的时间过长，那么都会带来活跃性或性能的问题。当执行时间较长的计算或者可能无法快速完成的操作时（例如网络IO或控制台IO），一定不要持有锁。
