JUC并发编程-共享模型不可变

简介: 日期转换的问题下面的代码在运行时,由于 SimpleDateFormat 不是线程安全的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);

日期转换的问题
下面的代码在运行时,由于 SimpleDateFormat 不是线程安全的

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();
}
1
2
3
4
5
6
7
8
9
10
有很大几率出现 java.lang.NumberFormatException 或者出现不正确的日期解析结果,例如:

我们有两种解决思路:

加锁
使用不可变类型
使用同步锁解决
这样虽能解决问题,但带来的是性能上的损失,并不算很好:

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();
}
1
2
3
4
5
6
7
8
9
10
11
12
使用不可变类型解决
如果一个对象在不能够修改其内部状态(属性),那么它就是线程安全的,因为不存在并发修改啊!这样的对象在 Java 中有很多,例如在 Java 8 后,提供了一个新的日期格式化类DateTimeFormatter :

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();
}
1
2
3
4
5
6
7
不可变对象,实际是另一种避免竞争的方式。

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

public final class String
implements java.io.Serializable, Comparable, 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

// ...

}
1
2
3
4
5
6
7
8
9
说明:

将类声明为final,避免被带外星方法的子类继承,从而破坏了不可变性。

将字符数组(在JDK8以前都是char数组)声明为final,也就是说只能在构造的时候被赋值,避免被修改

虽然将字符数组声明为final但是只能保证它的引用不会变,不能保证字符数组中的元素不发生变化,那么String是怎么处理的呢?
想要在不改变引用的情况下对字符数组的内容进行修改,那么只有可能是外界也引用了这个数组。为了杜绝这种情况,在使用字符数组的构造方法的时候,是进行了复制的。

hash虽然不是final的,但是其只有在调用hash()方法的时候才被赋值,除此之外再无别的方法修改。

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);
}
1
2
3
4
5
6
7
8
9
10
发现其内部是调用 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);
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
结果发现也没有,构造新字符串对象时,会生成新的 char[] value,对内容进行复制 。

这种通过创建副本对象(肯定是新的对象,所以不会被共享)来避免共享的手段称之为【保护性拷贝(defensive copy)】

享元模式
在不可变设计中其核心思想就是创建新对象来避免被其他线程共享,从而引发安全问题。这种方法的缺点就是对象创建的太频繁,对象个数可能会非常的多,从而频繁的引发垃圾回收影响效率。
为了解决这种问题,我们一般会将不可变类关联一个设计模式,也就是享元模式。他是我们二十四种设计模式之一

英文名称:Flyweight pattern.

使用场景:当需要重用数量有限的同一类对象时

核心思想:对相同取值的对象进行共享

享元模式的体现
包装类

注意:所有包装类都是不可变类型

在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 cache
return LongCache.cache[(int)l + offset];
}
return new Long(l);
}
1
2
3
4
5
6
7
注意:

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

详见jvm

BigDecimal BigInteger(不可变、线程安全)

一部分数字使用了享元模式进行了缓存。

手动实现一个连接池
例如:一个线上商城应用,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 {
// 实现略
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
使用连接池:

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();
}
1
2
3
4
5
6
7
8
9
10
11
12
以上实现没有考虑:

连接的动态增长与收缩
连接保活(可用性检测)
等待超时处理
分布式 hash
对于关系型数据库,有比较成熟的连接池实现,例如c3p0, druid等 对于更通用的对象池,可以考虑使用apache commons pool,例如redis连接池可以参考jedis中关于连接池的实现

final的原理
设置 final 变量的原理
理解了 volatile 原理,再对比 final 的实现就比较简单了

public class TestFinal {
final int a = 20;
}
1
2
3
字节码

0: aload_0
1: invokespecial #1 // Method java/lang/Object."":()V
4: aload_0
5: bipush 20
7: putfield #2 // Field a:I
<-- 写屏障
10: return
1
2
3
4
5
6
7
发现 final 变量的赋值也会通过 putfield 指令来完成,同样在这条指令之后也会加入写屏障,这样对final变量的写入不会重排序到构造方法之外,保证在其它线程读到 它的值时不会出现为 0 的情况。普通变量不能保证这一点了。

读取final变量原理
有以下代码:

public class TestFinal {
final static int A = 10;
final 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 {

        @Override
        public 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);
}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
反编译UseFinal1中的test方法:

public test()V
L0
LINENUMBER 31 L0
GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
BIPUSH 10
INVOKEVIRTUAL java/io/PrintStream.println (I)V
L1
LINENUMBER 32 L1
GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
LDC 32768
INVOKEVIRTUAL java/io/PrintStream.println (I)V
L2
LINENUMBER 33 L2
GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
NEW cn/itcast/n5/TestFinal
DUP
INVOKESPECIAL cn/itcast/n5/TestFinal. ()V
INVOKEVIRTUAL java/lang/Object.getClass ()Ljava/lang/Class;
POP
BIPUSH 20
INVOKEVIRTUAL java/io/PrintStream.println (I)V
L3
LINENUMBER 34 L3
GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
NEW cn/itcast/n5/TestFinal
DUP
INVOKESPECIAL cn/itcast/n5/TestFinal. ()V
INVOKEVIRTUAL java/lang/Object.getClass ()Ljava/lang/Class;
POP
LDC 2147483647
INVOKEVIRTUAL java/io/PrintStream.println (I)V
L4
LINENUMBER 35 L4
NEW cn/itcast/n5/TestFinal
DUP
INVOKESPECIAL cn/itcast/n5/TestFinal. ()V
INVOKEVIRTUAL cn/itcast/n5/TestFinal.test1 ()V
L5
LINENUMBER 36 L5
RETURN
L6
LOCALVARIABLE this Lcn/itcast/n5/UseFinal1; L0 L6 0
MAXSTACK = 3
MAXLOCALS = 1
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
可以看见,jvm对final变量的访问做出了优化:另一个类中的方法调用final变量时,不是从final变量所在类中获取(共享内存),而是直接复制一份到方法栈栈帧中的操作数栈中(工作内存),这样可以提升效率,是一种优化。

总结:

对于较小的static final变量:复制一份到操作数栈中
对于较大的static final变量:复制一份到当前类的常量池中
对于非静态final变量,优化同上。
final总结
final关键字的好处:

(1)final关键字提高了性能。JVM和Java应用都会缓存final变量。

(2)final变量可以安全的在多线程环境下进行共享,而不需要额外的同步开销。

(3)使用final关键字,JVM会对方法、变量及类进行优化。

关于final的重要知识点

1、final关键字可以用于成员变量、本地变量、方法以及类。

2、final成员变量必须在声明的时候初始化或者在构造器中初始化,否则就会报编译错误。

3、你不能够对final变量再次赋值。

4、本地变量必须在声明时赋值。

5、在匿名类中所有变量都必须是final变量。

6、final方法不能被重写。

7、final类不能被继承。

8、final关键字不同于finally关键字,后者用于异常处理。

9、final关键字容易与finalize()方法搞混,后者是在Object类中定义的方法,是在垃圾回收之前被JVM调用的方法。

10、接口中声明的所有变量本身是final的。

11、final和abstract这两个关键字是反相关的,final类就不可能是abstract的。

12、final方法在编译阶段绑定,称为静态绑定(static binding)。

13、没有在声明时初始化final变量的称为空白final变量(blank final variable),它们必须在构造器中初始化,或者调用this()初始化。不这么做的话,编译器会报错“final变量(变量名)需要进行初始化”。

14、将类、方法、变量声明为final能够提高性能,这样JVM就有机会进行估计,然后优化。

15、按照Java代码惯例,final变量就是常量,而且通常常量名要大写。

16、对于集合对象声明为final指的是引用不能被更改,但是你可以向其中增加,删除或者改变内容。

无状态
在 web 阶段学习时,设计 Servlet 时为了保证其线程安全,都会有这样的建议,不要为 Servlet 设置成员变量,这 种没有任何成员变量的类是线程安全的 。

因为成员变量保存的数据也可以称为状态信息,因此没有成员变量就称之为【无状态】
————————————————
版权声明:本文为CSDN博主「十八岁讨厌编程」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/zyb18507175502/article/details/128892183

目录
相关文章
|
缓存 安全 Java
JUC并发编程-共享模型无锁
CAS 与 volatile CAS概述 CAS的全称是: Compare And Swap(比较再交换),它体现的一种乐观锁的思想,在无锁情况下保证线程操作共享数据的原子性。 在JUC( java.util.concurrent )包下实现的很多类都用到了CAS操作 AbstractQueuedSynchronizer(AQS框架) AtomicXXX类 例子: 我们基于JMM内存模型进行说明 线程1与线程2都从主内存中获取变量int a = 100,同时放到各个线程的工作内存中 一个当前内存值V、旧的预期值A、即将更新的值B,当且仅当旧的预期值A和内存值V相同时,将内存值修
34 0
|
5月前
|
安全 Java 开发工具
【Java并发基础】管程简介
【Java并发基础】管程简介
|
5月前
|
存储 安全 Java
Java并发基础-线程间通信
Java并发基础-线程间通信
20 0
|
6月前
|
算法 安全 Java
Java多线程基础-14:并发编程中常见的锁策略(一)
乐观锁和悲观锁是并发控制的两种策略。悲观锁假设数据容易产生冲突,因此在读取时即加锁,防止其他线程修改,可能导致效率较低。
55 0
|
6月前
|
安全 Java 调度
Java多线程基础-14:并发编程中常见的锁策略(二)
这段内容介绍了互斥锁和读写锁的概念以及它们在多线程环境中的应用。互斥锁仅允许进入和退出代码块时加锁和解锁,而读写锁则区分读和写操作,允许多个线程同时读但写时互斥。
50 0
|
6月前
|
Java
高并发编程之JUC 三大辅助类和读写锁
高并发编程之JUC 三大辅助类和读写锁
50 1
|
6月前
|
Java API 调度
[Java并发基础]多进程编程
[Java并发基础]多进程编程
123 0
《JUC并发编程 - 高级篇》03 - 共享对象之管程 上篇(共享带来的问题 | synchronized | 线程八锁 | 线程安全类)(二)
《JUC并发编程 - 高级篇》03 - 共享对象之管程 上篇(共享带来的问题 | synchronized | 线程八锁 | 线程安全类)
《JUC并发编程 - 高级篇》03 - 共享对象之管程 上篇(共享带来的问题 | synchronized | 线程八锁 | 线程安全类)(二)
|
消息中间件 存储 安全
《Java 并发编程》共享模型之管程
《Java 并发编程》共享模型之管程
145 0
《Java 并发编程》共享模型之管程
|
存储 缓存 安全
《Java 并发编程》共享模型之无锁
《Java 并发编程》共享模型之无锁
103 0
《Java 并发编程》共享模型之无锁