JVM 如何确保新对象内存分配的线程安全

线程安全

代码本身封装了所有必要的正确性保障手段（如互斥同步等），令调用者无需关心多线程下的调用问题，更无须自己实现任何措施来保证多线程环境下的正确调用。

Java语言中的线程安全

按照线程安全的“安全强度”由强至弱排序，将Java语言中各种操作共享的数据分为：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立

1. 不可变

Java语言里，不可变（Immutable）的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再进行任何线程安全保障措施。

final关键字修饰的基本数据类型或者类似于java.lang.String类的对象实例就是线程安全的（String类的substring()、replace()和concat()方法不会影响原来的值，只会返回一个新构造的字符串对象。

2. 绝对线程安全

java.util.Vector是一个线程安全的容器，它的各个方法均是被synchronized修饰，具备了原子性、可见性和有序性。但调用它的时候并不意味着不再需要同步手段

分析：使用的Vector的get()、remove()和size()方法是同步的，但是多线程环境下不在方法调用端做额外的同步措施，代码仍然是不安全的。因为如果另一个线程恰好在错误的时间里删除了一个元素，导致序号i已经不再可用，再用i访问数组就会抛出一个ArrayIndexOutOfBoundsException异常。因此合理的改动是：

假如Vector一定要做到绝对的线程安全，那就必须在它内部维护一组一致性的快照访问才行，每次对其中元素进行改动都要产生新的快照，付出的时间和空间成本非常大

3. 相对线程安全

保证对这个对象单次的操作是线程安全的，在调用的时候不需要额外的保障措施，但是对于一些特定顺序的连续调用，就需要调用端使用额外的同步手段来保证调用的正确性

Java语言中例如Vector、HashTable、Collections的synchronizedCollection()方法包装的集合等

线程安全的实现方法

1. 互斥同步（Mutual Exclusion & Synchronization）

同步是指多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条（或者是一些，当使用信号量的时候）线程使用。

互斥是实现同步的一种手段，临界区（Critical Section）、互斥量（Mutex）、信号量（Semaphore）都是常见的互斥实现方式。

最基本的互斥同步手段是synchronized关键字——块结构（Block Structured）同步语法。synchronized关键字经过javac编译后，会在同步块前后分别形成monitorenter和monitorexit这两个字节码指令。Java源码中synchronized若是以synchronized()形式，则依据括号中的对象或者.class来对其加锁，若是synchronized修饰在方法上，则观察该方法是普通方法（synchronized修饰该方法对象this）还是静态（static）方法（修饰该方法对象的类.class）

加锁前后会有锁的计数器来作为判断依据，指令码执行monitorenter时，如果对象没被锁定或当前线程持有该对象的锁则计数器加1，执行monitorexit指令时，计数器减1，当计数器为0时，则锁被释放。获取所失败的线程会被阻塞等待，直至线程释放锁后重新竞争锁。

synchronized直接推论：

被synchronized修饰的同步块对同一线程来说是可重入的。这意味着同一线程反复进入同步块也不会出现自己把自己锁死的情况

被synchronized修饰的同步块在持有锁的线程执行完毕并释放锁之前，会无条件的阻塞后面其它线程的进入。这意味着无法像处理某些数据库中的锁那样，强制已获取锁的的线程释放锁；也无法强制正在等待锁的线程中断等待或者超时退出

synchronized持有锁是一个重量级（Heavy- Weight）操作执行成本较高。主流的Java虚拟机实现中，Java的线程是映射到操作系统的原生内核线程之上的，如果要阻塞或者唤醒一条线程，则需要操作系统来帮忙完成，这就不可避免的陷入用户态到核心态的转换中，进行这种状态转换需要耗费很多的处理器时间。尤其是对于代码特别简单的同步块（被synchronized修饰的getter()或setter()方法），状态转换消耗的时间甚至会比用户代码本身执行的时间还要长。

ReentrantLock相较于sychronized增加了一些高级功能，主要有以下三项：等待可中断、可实现公平锁及可以绑定多个条件

• 等待可中断：是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。可中断特性对处理执行时间非常长的同步块很有帮助

• 公平锁：是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序依次获得锁，但一旦使用公平锁，将导致ReentrantLock的性能急剧下降，会明显影响吞吐量

• 锁绑定多个条件：是指一个ReentrantLock对象可以同时绑定多个Condition对象。多次调用newCondition()方法即可。

synchronized和ReentrantLock性能对比结论：synchronized在经过多次优化下，两者性能上基本持平。

推荐使用synchronized：

• 需要基本的同步功能

• 考虑到Lock需要确保finally块中需要释放锁，否则抛出异常

非阻塞同步（Non-Blocking Synchronization）

CAS指令需要有三个操作数，分别是内存位置（在Java中科技简单地理解为变量的内存地址，用V表示）、旧的预期值（用A表示）和准备设置的新值（用B表示）。CAS指令执行时，当且仅当V符合A时，处理器才会用B更新V的值，否则它就不执行更新。但是，不管是否更新了V的值，都会返回V的旧值，上述的处理过程是一个原子操作，执行期间不会被其它线程中断。

CAS操作避免阻塞同步示例：

使用Atomic Integer代替int后，程序输出了正确的结果。这一切都要归功于incrementAndGet()方法的原子性。

“ABA问题”：如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然为A值，不能说明它的值没有被其他线程改变过，因为如果这段时间它的值曾经被改成B，后来又改回A，那CAS操作就会误认为它从来没有被改过。

解决策略：J.U.C包为了解决这个问题，提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。不过大部分ABA问题不会影响程序并发的正确性，如果解决ABA问题，改用传统的互斥同步可能会比原子类更为高效。

无同步方案

天生线程安全的代码类：

可重入代码（Reentrant Code）：又称纯代码（Pure Code），是指可以在代码执行的任何时刻中断它，转而去执行另外一段代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误，也不会对结果有所影响。在特指多线程的上下文语境里（不涉及信号量等因素），可重入代码是线程安全代码的一个真子集，这意味着相对于线程安全来说，可重入性是更为基础的特性，它可以保证代码线程安全，即所有可重入的代码都是线程安全的，但并非所有线程安全的代码都是可重入的。可重入代码的判断依据：如果一个方法的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果，那它就满足可重入性的要求，当然也就是线程安全的。

线程本地存储（Thread Local Storage）：如果一段代码所需要的数据必须与其他代码共享，那就看看共享数据的代码是否能保证在同一个线程中执行。如果能保证，就可以把共享数据的可见范围限制在同一个线程之内，这样，无须同步也能保证线程之间不出现数据争用的问题。符合这种特点的应用如消费队列的架构模式（如“生产者-消费者”模式），应用实例就是经典web交互模型中的“一个请求对应一个服务器线程”（Thread-per- Request）的处理方式

Java语言中，如果一个变量要被多线程访问，可以使用volatile关键字将它声明为“易变的”；如果一个变量只要被某个线程独享，Java中就没有类似C++中_declspec(thread)这样的关键字去修饰，不过还是可以通过java.lang.ThreadLocal类来实现线程本地存储的功能。每个线程的Thread对象中都有一个ThreadLocalMap对象，这个对象存储了一组以ThreadLocal.threadLocalHashCode为键，以本地线程变量为值的K-V值对，ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值，使用这个值就可以在线程K-V值对中找回对应的本地线程变量。