为什么 java.concurrent.atomic 里面没有 String

2022-04-17

首先说结论，String 是线程安全的，不会造成多线程读写冲突问题。

原因如下：String 不是基础类型，而是一个不可变类，我们无法改变一个 String 对象的内容，而只能创建一个新的 String 对象。atomic 包是一个工具包，并不能替代原来的基础类型和对象的使用，因此用 atomic 去封装 String 没有任何用处。atomic 包中常用的类有 AtomicInteger、AtomicReference，常用的方法有 compareAndSet()、getAndIncrement()。

Atomic 原子类用的不是传统的锁机制（synchronized、ReentrantLock 等悲观锁），而是用的无锁化的 CAS 机制（乐观锁），通过 CAS 机制保证多线程修改的安全性，CAS的全称是：Compare and Set，也就是先比较再设置的意思（有的地方也叫 Compare and Swap）。

1.String 的不可变特性

String 是被 final 修饰的，无论调用 String 的什么方法，均无法修改 this 对象的状态。当确实需要修改 String 的值时，它的办法是构造一个新的 String 返回，这与可以直接修改原值的基础类型大不相同。其本质是 String 对象中的 value[] 字符数组不可变，而声明的 String 类型的变量指向的引用是可以变的。

public static void main(String[] args) {
    String origin = "Test";
    // replace 不会改变 this 对象（即 origin 对象）的任何状态
    String target = origin.replace("T", "t");
    System.out.println(origin);//输出 Test
    System.out.println(target);//输出 test
    
    int i = 0;
    i++;//会直接改变原来的 i 的值
    
    int[] intArr = new int[]{0};
    changeValue(intArr);//传递的是数组的引用，因此方法内部对数组的修改会影响原数组
    System.out.println("piece 1: " + intArr[0]);//输出 piece 1: 1
    String str = new String("apple");
    changeValue(str);//传递的也是引用，但由于字符串对象不可变，因此方法内部的操作不会影响原字符串
    System.out.println("piece 2: " + str);//输出 piece 2: apple
}

public static void changeValue(int[] intArr) {
    intArr[0] = 1;
}

public static void changeValue(String str) {
    // 虽然变量名都叫 str，但是这里相当于是重新声明的一个局部字符串变量，
    // 与调用此方法时传入的那个变量 str 是完全不同的，如果把两个名字改成
    // 像 origin / target 这种就看得明白些。因此这个方法的局部变量 str 
    // 一开始指向的是 "apple" 的引用，当 "pear" 出现后，JVM 就在字符串
    // 常量池中创建了一个新的 "pear" 对象，并让局部变量 str 指向它。
    System.out.println(str);//输出 apple
    str = "pear";//这里是把 "pear" 的引用赋给局部变量 str，不会影响原来的字符串对象
    System.out.println(str);//输出 pear
}

其实不光是 String 对象，Java 中的很多对象都符合上述不可变状态的特性，比如 Integer、Double、Long 等所有原生类型的包装器类型所创建的对象，也都是不可变的。那么明明可以直接修改 this 对象，为何还要大费周章地构造一个全新的对象返回呢？

2.不可变对象的优点

2.1 对并发友好

提到多线程并发，最让人苦恼的莫过于对共享资源的访问冲突，目前在大多数语言中，对多线程冲突问题常采用同步的方式解决，比如 Java 中的 synchronized 关键字和 Lock 对象等机制，但这个方式有个弊端：冲突能否被解决，完全取决于程序员对共享资源加锁和解锁的时机对不对。所以还有另一个方向，就是从多线程冲突的原因——共享资源上入手。

如果完全没有共享资源，那自然就不存在访问冲突了，Java 中的 ThreadLocal 机制就是利用了这一理念。但是大多数时候，线程间是需要使用共享资源互通信息的，那如果共享资源能够自诞生之后就不再变更呢？不可变对象就是这样一种诞生之后就完全不再变更的对象，天生支持多线程间共享。

某个线程想要修改共享资源 A 的状态时，不去直接修改 A 本身的状态，而是先在本线程中构造一个新状态的共享资源 B，待 B 构造完成后，再用 B 替换 A，由于对引用赋值这个操作是原子性的，所以不会造成线程冲突问题。但是需要注意可见性问题，如果想要 B 替换 A 之后，其他所有线程能实时感知到变化，就要用 volatile 关键字保证可见性和有序性。

public class Test {
    private volatile String shared = "shared";// volatile 保证可见性和有序性
    public void test() {
        new Thread(() -> {
            String newValue = shared.replace("s", "S");// 构建一个新 String
            shared = newValue;// 用新 String 替换共享资源，引用的赋值是原子性的
        }).start();
    }
}

值得注意的是，线程安全需同时考虑原子性、可见性和有序性问题，所以网上常说的不可变对象是线程安全的，其实并不严谨。

所有的函数式编程语言，如 Lisp、Erlang 等，都从语法层面保证了只能使用不可变对象，所以所有函数式编程语言天生对并发友好，这也是在一些高并发场景中，函数式编程语言更受青睐的原因。

2.2 易于缓存

当一个对象被频繁访问，而生成该对象的开销较大时，则需要进行缓存，比如存入一个缓存集合（如 ConcurrentHashMap）。但使用缓存就不得不面对缓存污染问题，即缓存对象的状态有可能被上层业务代码修改，这会导致出现业务数据之间互相干扰等问题。通常的解决方案是返回原始缓存对象的一个深拷贝，这样无论上层业务代码对缓存对象如何修改，均不会对缓存本身造成影响。

但是深拷贝毕竟有额外的性能开销，此时如果缓存的是不可变对象，就皆大欢喜了。因为你可以放心大胆的把缓存对象的引用返回给上层代码使用，因为无论上层代码怎样操作，它也无法修改一个不可变对象的状态，这也就天然规避了缓存污染问题。

3.不可变对象的局限

3.1 编程思维的转变

如果所有对象都被设计为不可变的，等价于使用函数式编程思维，编程思维上的变化并非所有程序员都能很好的适应，如果适应不了，强行推广只会适得其反。况且 Java 本身也并不是纯粹的函数式编程语言。

3.2 性能上的额外开销

由于修改不可变对象时都会生成一个新对象，如果设计和使用不当的话，可能形成性能瓶颈点。有人可能就想到了用 StringBuffer（线程安全）或 StringBuilder（线程不安全）来解决这个问题，这两个类都是对对象本身直接进行操作，不会生成新的对象。

但是不必过于担心性能问题，一方面内存拷贝速度极快，另外也并非所有额外的性能开销都是不可容忍的，代码性能测试时，你可能会发现很多各式各样的性能瓶颈点，大部分都是意想不到的，所以过早考虑性能而放弃编码安全是不可取的。就好比汇编效率最高，但是也不会因此所有代码都直接用汇编编程，遇到真正的性能瓶颈时，有针对性的做汇编层面的调优才是上策。

4.建议

在自己能力范围内，尽量优先考虑使用不可变对象的设计，如果真的引发了性能瓶颈，再有针对性地做出调整即可。