要编写线程安全的代码，其核心在于要对状态访问操作进行管理，特别是对共享的(Shared)和（且）可变的(Mutable)状态的访问。
对象的状态是指存储在状态变量（例如实例或静态域）中的数据。对象的状态可能包括其他依赖对象的域。在对象的状态中包含了任何可能影响其外部可见行为的数据。
共享：变量可以由多个线程同时访问
可变：变量的值在其生命周期内可以发生变化
一个对象是否需要是线程安全的，取决于它是否被多个线程访问。要使得对象是线程安全的，需要采用同步机制来协同对对象（共享）可变状态的访问。
同步机制的实现：
- synchronized关键字
- volatile类型的变量
- 显式锁(Explicit Lock)
- 原子变量
从一开始就设计一个线程安全的类，要比在以后再将这个类修改为线程安全的类要容易得多。
访问某个变量的代码越少，就越容易确保对变量的所有访问都实现正确同步。因此，程序状态的封装性越好，就越容易实现程序的线程安全性。
当性能测试结果和应用需求告诉你必须提高性能，以及测量结果表明这种优化在实际环境中确实能够带来性能优化时，才进行优化。在编写并发代码时，应该始终遵循这个原则。由于并发错误是非常难以重现和调试的，因此如果只是在某段很少执行的代码路径上获得了性能提升，那么很可能被程序运行时存在的失败风险而抵消。
区分：
- 线程安全类
- 线程安全程序
- 线程安全性
完全由线程安全类构成的程序不一定就是线程安全的，而在线程安全程序中也可以包含非线程安全的类。只有当类中只包含自己的状态时，线程安全类才是有意义的。线程安全性只与状态相关，因此只能应用于封装其状态的整个代码，这可能是一个对象，也可能是整个程序。
2.1 什么是线程安全性
单线程的正确性：（近似）所见即所知
线程安全性：当多个线程访问某个类时，这个类始终能表现出正确的行为，那么就称这个类是线程安全的。
在线程安全类中封装了必要的同步机制，因此客户端无须进一步采取同步措施。
无状态对象（即没有实例变量的对象）一定是线程安全的。
2.2 原子性
竞争条件(Race Condition)：由于不恰当的执行时序而出现不正确的结果
2.2.1 竞争条件
最常见的竞争条件类型是“先检查后执行(Check-Then-Act)”操作，即通过一个可能失效的观测结果来决定下一步的动作——基于一种可能失效的观察结果来做出判断或者执行某个计算
2.2.2 示例：（延迟初始化）中的竞争条件
eg.非线程安全的单例
2.2.3 复合操作
原子操作
在java.util.concurrent.atomic包中包含了一些原子变量类，用于实现在数值和对象引用上的原子状态转换。
当在无状态的类中添加一个状态时，如果该状态完全由线程安全的对象类管理，那么这个类仍然是线程安全的。**
在实际情况中，应尽可能地使用现有的线程安全对象来管理类的状态。与非线程安全的对象相比，判断线程安全对象的可能状态及其状态转换情况要更为容易，从而也更容易维护和验证线程安全性。
2.3 加锁机制
当在不变性条件中涉及多个变量时，各个变量之间并不是彼此独立的，而是某个变量的值会对其他变量的值产生约束。因此，当更新某一个变量时，需要在同一个原子操作中对其他变量同时进行更新。
要保持状态的一致性，就需要在单个原子操作中更新所有相关的状态变量。**
2.3.1 内置锁
内置的支持原子性的锁机制——Synchronized Block：
- 锁的对象引用
- 由这个锁保护的代码块
每个Java对象都可以用做一个实现同步的锁，这些锁被称为内置锁(Intrinsic Lock)或监视器锁(Monitor Lock)。线程在进入同步代码块之前会自动获得锁，并且在退出同步代码块时自动释放锁，而无论是通过正常的控制路径退出，还是通过从代码块中抛出异常退出，获得内置锁的唯一途径就是进入由这个锁保护的同步代码块或方法。
内置锁相当于一种互斥锁。
2.3.2 重入
如果某个线程试图获得一个已经由它自己持有的锁，那么这个请求就会成功。
重入意味着获取锁的操作的粒度是“线程”而不是“调用”。
重入的一种实现方法是，为每个锁关联一个获取计数值和一个所有者线程。
2.4 用锁来保护状态
如果用同步来协调对某个变量的访问，那么在访问这个变量的所有位置上都需要使用同步。而且，当使用锁来协调对某个变量的访问时，在访问变量的所有位置上都要使用同一个锁。**
当获取与对象关联的锁时，并不能阻止其他线程访问该对象，某个对象在获得对象的锁之后，只能阻止其他线程获得同一个锁。之所以每个对象都有一个内置锁，只是为了免去显式地创建锁对象。
一种常见的加锁约定是，将所有的可变状态都封装在对象内部，并通过对象的内置锁对所有访问可变状态的代码路径进行同步，使得在该对象上不会发生并发访问。
滥用同步
- 活跃性问题或性能问题
- 只是将每个方法都作为同步方法，并不足以确保复合操作都是原子的**
2.5 活跃性与性能
不良并发(Poor Concurrency)应用程序：可同时调用的数据量，不仅受到可用处理资源的限制，还受到应用程序本身结构的限制。
通过缩小同步代码块的作用范围可以做到确保程序的并发性同时维护线程安全性。要确保同步代码块不要过小，并且不要将本应是原子的操作拆分到多个同步代码块中，应该尽量将不影响共享状态且执行时间较长的操作从同步代码块中分离出去，从而在这些操作的执行过程中，其他线程可以访问共享状态。**
eg.
局部变量无需同步，不会在多个线程间共享。
对在单个变量上实现原子操作来说，原子变量是很有用的，但由于我们已经使用了同步代码块来构造原子操作，而使用两种不同的同步机制不仅会带来混乱，也不会在性能或安全性上带来任何好处，因此在这里不使用原子变量。
在获取与释放锁等操作上都需要一定的开销，因此如果将同步代码块分解得过细，那么通常并不好。
如果持有锁的时间过长（执行计算密集的操作或某个可能阻塞的操作），那么会带来活跃性或性能问题。
要判断同步代码块的合理大小，需要在各种设计需求之间进行权衡，包括安全性、简单性和性能**。
网友评论