并发编程（5）共享模型之不可变

7 共享模型之不可变

本章内容

不可变类的使用
不可变类设计
无状态类设计

7.1 日期转换的问题

问题提出

下面的代码在运行时，由于 SimpleDateFormat 不是线程安全的,

有很大几率出现 java.lang.NumberFormatException 或者出现不正确的日期解析结果，

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");for (int i = 0; i < 10; i++) {new Thread(() -> {try {log.debug("{}", sdf.parse("1951-04-21"));} catch (Exception e) {log.error("{}", e);}}).start();
}

例如：

思路 - 同步锁

这样虽能解决问题，但带来的是性能上的损失，并不算很好：

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");for (int i = 0; i < 50; i++) {new Thread(() -> {synchronized (sdf) {try {log.debug("{}", sdf.parse("1951-04-21"));} catch (Exception e) {log.error("{}", e);}}}).start();
}

思路 - 不可变

如果一个对象在不能够修改其内部状态（属性），那么它就是线程安全的，因为不存在并发修改啊！

这样的对象在Java 中有很多，例如在 Java 8 后，提供了一个新的日期格式化类：

DateTimeFormatter dtf = DateTimeFormatter.ofPattern("yyyy-MM-dd");for (int i = 0; i < 10; i++) {new Thread(() -> {LocalDate date = dtf.parse("2018-10-01", LocalDate::from);log.debug("{}", date);}).start();
}

可以看 DateTimeFormatter 的文档：

@implSpec
This class is immutable and thread-safe.

不可变对象，实际是另一种避免竞争的方式。

7.2 不可变设计

另一个大家更为熟悉的 String 类也是不可变的，以它为例，说明一下不可变设计的要素

public final class String implements java.io.Serializable, Comparable<String>, CharSequence {/** The value is used for character storage. */private final char value[];/** Cache the hash code for the string */private int hash; // Default to 0// ...}

final 的使用

发现该类、类中所有属性都是 final 的

属性用 final 修饰保证了该属性是只读的，不能修改
类用 final 修饰保证了该类中的方法不能被覆盖，防止子类无意间破坏不可变性

保护性拷贝

但有同学会说，使用字符串时，也有一些跟修改相关的方法啊，比如 substring 等，

那么下面就看一看这些方法是如何实现的，就以 substring 为例：

public String substring(int beginIndex) {if (beginIndex < 0) {throw new StringIndexOutOfBoundsException(beginIndex);}int subLen = value.length - beginIndex;if (subLen < 0) {throw new StringIndexOutOfBoundsException(subLen);}return (beginIndex == 0) ? this : new String(value, beginIndex, subLen);
}

发现其内部是调用 String 的构造方法创建了一个新字符串，

再进入这个构造看看，是否对 final char[] value 做出了修改：

public String(char value[], int offset, int count) {if (offset < 0) {throw new StringIndexOutOfBoundsException(offset);}if (count <= 0) {if (count < 0) {throw new StringIndexOutOfBoundsException(count);}if (offset <= value.length) {this.value = "".value;return;}}if (offset > value.length - count) {throw new StringIndexOutOfBoundsException(offset + count);}this.value = Arrays.copyOfRange(value, offset, offset+count);
}

结果发现也没有，构造新字符串对象时，会生成新的 char[] value，对内容进行复制。

这种通过创建副本对象来避免共享的手段称之为【保护性拷贝（defensive copy）】

模式之享元 (池)

1. 简介

定义英文名称：Flyweight pattern. 当需要重用数量有限的同一类对象时 .

wikipedia： A flyweight is an object that minimizes memory usage by sharing as much data as possible with other similar objects

flyweight是一种通过与其他类似对象共享尽可能多的数据来最小化内存使用的对象

出自 “Gang of Four” design patterns

归类 Structual patterns

2. 体现

2.1 包装类

在JDK中 Boolean，Byte，Short，Integer，Long，Character 等包装类提供了 valueOf 方法，例如 Long 的valueOf 会缓存 -128~127 之间的 Long 对象，在这个范围之间会重用对象，大于这个范围，才会新建 Long 对象：

public static Long valueOf(long l) {final int offset = 128;if (l >= -128 && l <= 127) { // will cachereturn LongCache.cache[(int)l + offset];}return new Long(l);
}

注意：

Byte, Short, Long 缓存的范围都是 -128~127
Character 缓存的范围是 0~127
Integer的默认范围是 -128~127
- 最小值不能变
- 但最大值可以通过调整虚拟机参数 -Djava.lang.Integer.IntegerCache.high 来改变
Boolean 缓存了 TRUE 和 FALSE

2.2 String 串池

参见jvm课程

2.3 BigDecimal BigInteger

参见源码

这些类的单个方法是线程安全的,但多个方法的组合使用如果也要保证线程安全就需要使用锁来保护了

3. DIY 自定义数据库连接池

例如：一个线上商城应用，QPS 达到数千，如果每次都重新创建和关闭数据库连接，性能会受到极大影响。

这时预先创建好一批连接，放入连接池。一次请求到达后，从连接池获取连接，使用完毕后再还回连接池，

这样既节约了连接的创建和关闭时间，也实现了连接的重用，不至于让庞大的连接数压垮数据库。

class Pool {// 1. 连接池大小private final int poolSize;// 2. 连接对象数组private Connection[] connections;// 3. 连接状态数组 0 表示空闲， 1 表示繁忙private AtomicIntegerArray states;// 4. 构造方法初始化public Pool(int poolSize) {this.poolSize = poolSize;this.connections = new Connection[poolSize];this.states = new AtomicIntegerArray(new int[poolSize]);for (int i = 0; i < poolSize; i++) {connections[i] = new MockConnection("连接" + (i+1));}}// 5. 借连接public Connection borrow() {while(true) {for (int i = 0; i < poolSize; i++) {// 获取空闲连接if(states.get(i) == 0) {if (states.compareAndSet(i, 0, 1)) {log.debug("borrow {}", connections[i]);return connections[i];}}}// 如果没有空闲连接，当前线程进入等待synchronized (this) {try {log.debug("wait...");this.wait();} catch (InterruptedException e) {e.printStackTrace();}}}}// 6. 归还连接public void free(Connection conn) {for (int i = 0; i < poolSize; i++) {if (connections[i] == conn) {states.set(i, 0);synchronized (this) {log.debug("free {}", conn);this.notifyAll();}break;}}}}class MockConnection implements Connection {// 实现略
}

使用连接池：

Pool pool = new Pool(2);for (int i = 0; i < 5; i++) {new Thread(() -> {Connection conn = pool.borrow();try {Thread.sleep(new Random().nextInt(1000));} catch (InterruptedException e) {e.printStackTrace();}pool.free(conn);}).start();
}

以上实现没有考虑：

连接的动态增长与收缩
连接保活（可用性检测）
等待超时处理
分布式 hash

对于关系型数据库，有比较成熟的连接池实现，例如c3p0, druid等

对于更通用的对象池，可以考虑使用apache commons pool，例如redis连接池可以参考jedis中关于连接池的实现

原理之 final

1. 设置 final 变量的原理

理解了 volatile 原理，再对比 final 的实现就比较简单了

public class TestFinal {final int a = 20; 
}

字节码

发现 final 变量的赋值也会通过 putfifield 指令来完成，同样在这条指令之后也会加入写屏障，保证在其它线程读到

它的值时不会出现为 0 的情况

2. 获取 final 变量的原理

public class TestFinal {static int A = 10;static int B = Short.MAX_VALUE+1;final int a = 20;final int b = Integer.MAX_VALUE;final void test1() {final int c = 30;new Thread(()->{System.out.println(c);}).start();final int d = 30;class Task implements Runnable {@Overridepublic void run() {System.out.println(d);}}new Thread(new Task()).start();}}class UseFinal1 {public void test() {System.out.println(TestFinal.A);System.out.println(TestFinal.B);System.out.println(new TestFinal().a);System.out.println(new TestFinal().b);new TestFinal().test1();}
}class UseFinal2 {public void test() {System.out.println(TestFinal.A);}
}

需要从字节码层面看这段代码

匿名内部类访问的局部变量为什么必须要用final修饰

参考 https://blog.csdn.net/tianjindong0804/article/details/81710268

匿名内部类之所以可以访问局部变量，是因为在底层将这个局部变量的值传入到了匿名内部类中，

并且以匿名内部类的成员变量的形式存在，这个值的传递过程是通过匿名内部类的构造器完成的。

为什么需要用final修饰局部变量呢?

按照习惯，我依旧先给出问题的答案：用final修饰实际上就是为了保护数据的一致性。

这里所说的数据一致性，对引用变量来说是引用地址的一致性，对基本类型来说就是值的一致性。

这里我插一点，final修饰符对变量来说，深层次的理解就是保障变量值的一致性。为什么这么说呢？因为引用类型变量其本质是存入的是一个引用地址，说白了还是一个值（可以理解为内存中的地址值）。用final修饰后，这个这个引用变量的地址值不能改变，所以这个引用变量就无法再指向其它对象了。

回到正题，为什么需要用final保护数据的一致性呢？

因为将数据拷贝完成后，如果不用final修饰，则原先的局部变量可以发生变化。这里到了问题的核心了，如果局部变量发生变化后，匿名内部类是不知道的（因为他只是拷贝了局不变量的值，并不是直接使用的局部变量）。这里举个栗子：原先局部变量指向的是对象A，在创建匿名内部类后，匿名内部类中的成员变量也指向A对象。但过了一段时间局部变量的值指向另外一个B对象，但此时匿名内部类中还是指向原先的A对象。那么程序再接着运行下去，可能就会导致程序运行的结果与预期不同。

绍到这里，关于为什么匿名内部类访问局部变量需要加final修饰符的原理基本讲完了。

那现在我们来谈一谈JDK8对这一问题的新的知识点。在JDK8中如果我们在匿名内部类中需要访问局部变量，那么这个局部变量不需要用final修饰符修饰。看似是一种编译机制的改变，实际上就是一个语法糖（底层还是帮你加了final）。但通过反编译没有看到底层为我们加上final，但我们无法改变这个局部变量的引用值，如果改变就会编译报错。