Java并发编程实战笔记（一）：线程安全性

线程也被称为轻量级进程。由于同一个进程中的所有线程都将共享进程的内存地址空间，因此这些线程都能访问相同的变量并在同一个堆上分配对象，这就需要实现一种比在进程间共享数据粒度更细的数据共享机制。当多个线程访问某个状态变量并且其中有一个线程执行写入操作时，必须采用同步机制来协同这些线程对变量的访问。Java中的主要同步机制是关键字synchronized，它提供了一种独占加锁方式，但“同步”这个术语还包括volatile类型的变量，显示锁以及原子变量。

1. 线程安全性

在线程安全性的定义中，最核心的概念就是正确性。正确性的含义是，某个类的行为与其规范完全一致。在任何情况下，只有当类中仅包含自己的状态时，线程安全类才是有意义的。当多个线程访问某个类时，这个类始终都能表现出正确的行为，那么就称这个类是线程安全的。无状态对象一定是线程安全的。

2.原子性

在并发编程中，这种由于不恰当的执行时序而出现不正确结果是一种非常重要的情况，它有一个正式的名字：竞态条件（Race Condition）。最常见的竞态条件类型就是“先检查后执行（Check-Then-Act）”操作，即通过一个可能失效的观测结果来决定下一步的动作。使用“先检查后执行”的一种常见情况就是延迟初始化。延迟初始化的目的是将对象的初始化操作推迟到实际使用时才进行，同时要确保只被初始化一次。

@NotThreadSafepublic class LazyInitRace{private ExpensiveObject instance = null;public ExpensiveObject getInstance(){if(instance == null)instance = new ExpensiveObject();return instance;}}

在UnsafeCountingFactorizer的统计命中计数操作中存在另一种竞态条件，“读取-修改-写入”。

@NotThreadSafepublic class UnsafeCountingFactorizer implements Servlet {private long count = 0;public long getCount(){return count;}public void service(ServletRequest req, ServletResponse resp){BigInteger i = extractFromRequest(req);BigInteger[] factors = factor(i);++count;//读取-修改-写入，实际上包含了三个独立操作：读取count值，将值加1，然后将计算结果写入countencodeIntoResponse(resp,factors);}}

这里我们可以先用java.util.concurrent.atomic包中的原子变量类AtomicLong来替代long类型的计数器来改造代码，确保所有对计数器状态的访问操作都是原子的。

@ThreadSafepublic class CountingFactorizer implements Servlet {private final AtomicLong count = new AtomicLong(0);public long getCount(){return count.get();}public void service(ServletRequest req, ServletResponse resp){BigInteger i = extractFromRequest(req);BigInteger[] factors = factor(i);count.incrementAndGet();encodeIntoResponse(resp,factors);}}

当在无状态的类中添加一个状态时，如果该状态完全由线程安全的对象来管理，那么这个类仍然是线程安全的。

假定有两个操作A和B，如果从执行A的线程来看，当另一个线程执行B时，要么将B全部执行完，要么完全不执行B，那么A和B对彼此来说是原子的。原子操作是指，对于访问同一个状态的所有操作（包括该操作本身）来说，这个操作是一个以原子方式执行的操作。为了确保线程安全性，“先检查后执行”和“读取-修改-写入”等操作必须是原子的。我们将这样的操作统称为复合操作：包含一组必须以原子方式执行的操作以确保线程的安全性。

加锁机制

要保持状态的一致性，就需要在单个原子操作中更新所有相关的状态变量。Java提供了一种内置的锁机制来支持原子性：同步代码块（Synchronized Block）。同步代码块包含两部分：一个作为锁的对象引用，一个作为由这个锁保护的代码块。

synchronized（lock）{//访问或修改由锁保护的共享状态}

java的内置锁相当于一种互斥体（或互斥锁），这意味着最多只有一个线程能持有这种锁。当然使用锁会带来伸缩性和并发性能方面的问题。

这里提一个重入的概念，如果一个线程试图获得一个已经由它自己所持有的锁，那么这个请求就会成功。这意味着获取锁的操作粒度是线程，而不是“调用”。重入的实现方法是，为每个锁关联一个获取计数值和一个所有者线程。当计数值为0时，这个锁就是被认为是没有被任何线程持有。当线程请求一个未被持有的锁时，JVM将记下锁的持有者，并且将计数值置为1。如果同一个线程再次获取这个锁，计数值递增，而当线程退出同步代码块时，计数器会相应递减，当计数值为0时，这个锁被释放。重入进一步提升了加锁行为的封装性，简化了面向对象并发代码的开发。如果内置锁不是可重入的，那么下面的代码将会发生死锁。

public class Widget{public synchronized void doSomething(){...}}public class LoggingWidget extends Widget{public synchronized void doSomething(){super.doSomething();}}

用锁来保护状态

由于锁能使其保护的代码路径以串行形式来访问，因此可以通过锁来构造一些协议以实现对共享状态的独占访问。只要始终遵循这些协议，就能确保状态的一致性。一种常见的加锁约定是，将所有的可变状态都封装在对象内部，并通过对象的内置锁对所有访问可变状态的代码路径进行同步，使得在该对象上不会发生并发访问。
活跃性和性能

显而易见，内置锁的使用将有可能造成并发性能的问题。应该尽量将不影响共享状态且执行时间较长的操作从同步代码块中分离出去。要判断同步代码块的合理大小，需要在各种设计需求之间进行平衡，包括安全性、简单性和性能。