JUC学习笔记——共享模型之不可变

秋落雨微凉

发布于 2022-11-21 11:14:55

2750

发布于 2022-11-21 11:14:55

文章被收录于专栏：秋落雨微凉Java开发栏秋落雨微凉Java开发栏

JUC学习笔记——共享模型之不可变

在本系列内容中我们会对JUC做一个系统的学习，本片将会介绍JUC的不可变内容

我们会分为以下几部分进行介绍：

不可变案例
不可变设计
模式之享元
原理之final
无状态

不可变案例

我们下面通过一个简单的案例来讲解不可变的共享

案例展示

首先我们给出一个简单的不安全案例：

/*代码展示*/

// 首先我们都知道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();
}

/*结果展示*/

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

19:10:40.859 [Thread-2] c.TestDateParse - {} 
java.lang.NumberFormatException: For input string: "" 
 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
 at java.lang.Long.parseLong(Long.java:601) 
 at java.lang.Long.parseLong(Long.java:631) 
 at java.text.DigitList.getLong(DigitList.java:195) 
 at java.text.DecimalFormat.parse(DecimalFormat.java:2084) 
 at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:2162) 
 at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514) 
 at java.text.DateFormat.parse(DateFormat.java:364) 
 at cn.itcast.n7.TestDateParse.lambda$test1$0(TestDateParse.java:18) 
 at java.lang.Thread.run(Thread.java:748) 
19:10:40.859 [Thread-1] c.TestDateParse - {} 
java.lang.NumberFormatException: empty String 
 at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1842) 
 at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110) 
 at java.lang.Double.parseDouble(Double.java:538) 
 at java.text.DigitList.getDouble(DigitList.java:169) 
 at java.text.DecimalFormat.parse(DecimalFormat.java:2089) 
 at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:2162) 
 at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514) 
 at java.text.DateFormat.parse(DateFormat.java:364) 
 at cn.itcast.n7.TestDateParse.lambda$test1$0(TestDateParse.java:18) 
 at java.lang.Thread.run(Thread.java:748) 
19:10:40.857 [Thread-8] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951 
19:10:40.857 [Thread-9] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951 
19:10:40.857 [Thread-6] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951 
19:10:40.857 [Thread-4] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951 
19:10:40.857 [Thread-5] c.TestDateParse - Mon Apr 21 00:00:00 CST 178960645 
19:10:40.857 [Thread-0] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951 
19:10:40.857 [Thread-7] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951 
19:10:40.857 [Thread-3] c.TestDateParse - Sat Apr 21 00:00:00 CST 1951

同步锁解决

我们可以按照我们之前学习的锁的思路来解决并发问题；

/*代码展示*/

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();
}

不可变解决

但是我们可以选择更换一种日期类型，我们选择不可改变的日期类就可以完成并发下的数据修改问题：

/*代码展示*/

// DateTimeFormatter的所有赋值方法都是直接new一个新的对象然后进行赋值

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();
}

/*内容分析*/
如果一个对象在不能够修改其内部状态（属性），那么它就是线程安全的，因为不存在并发修改
    
不可变对象，实际是另一种避免竞争的方式。

不可变设计

我们下面讲解JDK中不可变的设计类

String类型设计

我们平时所使用的String类型就是无法修改的类：

/*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，避免被修改
hash虽然不是final的，但是其只有在调用hash()方法的时候才被赋值，除此之外再无别的方法修改。

final 的使用

我们的不可变设计中final的使用实际上是非常重要的：

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

保护性拷贝

我们在JDK的一些不可变设计类中发现我们是可以对其进行修改的：

例如String，我们可以采用赋值方法进行赋值
但是其实底层却不是直接采用赋值方法来实现的，底层是采用拷贝原String数组然后创建一个新String数据并进行赋值而产生的

我们给出一个简单的例子：

/*String的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);
    }
    
    // 我们这里发现，实际上最后返回的String实际上是调用构造方法产生的
    return (beginIndex == 0) ? this : new String(value, beginIndex, subLen);
}

/*String构造方法*/

// 发现其内部是调用 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);
}

我们最后会发现构造方法也没有对value进行修改，构造新字符串对象时，会生成新的 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);
}

/*内部设置展示*/

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

String 串池（不可变、线程安全）
BigDecimal BigInteger(不可变、线程安全)

案例

我们可以借助享元的思想来完成一个简单的连接池设计：

例如：一个线上商城应用，QPS 达到数千，如果每次都重新创建和关闭数据库连接，性能会受到极大影响。
这时预先创建好一批连接，放入连接池。一次请求到达后，从连接池获取连接，使用完毕后再还回连接池，这样既节约了连接的创建和关闭时间，也实现了连接的重用，不至于让庞大的连接数压垮数据库。

我们给出详细代码：

/*测试代码*/

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();
}

/*连接池代码展示*/

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;
            }
        }
    }
}

// 我们借助MockConnection来模拟连接池
class MockConnection implements Connection {
    // 实现略
}

原理之final

这一小节我们将介绍final的底层原理

设置原理

首先我们先来介绍一下final的设置原理：

/*代码*/

public class TestFinal {
    final int a = 20;
}

/*底层源码*/

0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: bipush 20
7: putfield #2 // Field a:I
 <-- 写屏障
10: return

我们会发现 final 变量的赋值也会通过 putfield 指令来完成，同样在这条指令之后也会加入写屏障

这样对final变量的写入不会重排序到构造方法之外，保证在其它线程读到它的值时不会出现为 0 的情况，普通变量不能保证这一点了。

获得原理

我们下面通过一个案例进行展示：

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);
    }
}

然后我们反编译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.<init> ()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.<init> ()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.<init> ()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
}

可以看见，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指的是引用不能被更改，但是你可以向其中增加，删除或者改变内容。

参考链接：Java中final实现原理的深入分析（附示例）-java教程-PHP中文网

无状态

我们这一小节来简单介绍一下无状态

无状态概述

首先我们来简述一下无状态：

无状态指的是对于请求方的每个请求，接收方都当这次请求是第一次请求。
成员变量保存的数据也可以称为状态信息，因此没有成员变量就称之为"无状态"
无状态并不代表接收方不会保存请求方的任何数据，它只是不保存与接收方可能的下次请求相关的数据。

那么无状态有什么优势：

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

结束语

到这里我们JUC的共享模型之不可变就结束了，希望能为你带来帮助~

附录

该文章属于学习内容，具体参考B站黑马程序员满老师的JUC完整教程

这里附上视频链接：07.001-本章内容_哔哩哔哩_bilibili

本文参与腾讯云自媒体分享计划，分享自作者个人站点/博客。

原始发表：2022-11-16，如有侵权请联系 cloudcommunity@tencent.com 删除

编程算法

jvm

c++

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体分享计划，欢迎热爱写作的你一起参与！

编程算法

jvm

c++

登录后参与评论

0 条评论

热度

JUC学习笔记——共享模型之不可变

JUC学习笔记——共享模型之不可变

JUC学习笔记——共享模型之不可变

不可变案例

案例展示

同步锁解决

不可变解决

不可变设计

String类型设计

final 的使用

保护性拷贝

模式之享元

定义

体现

案例

原理之final

设置原理

获得原理

final总结

无状态

无状态概述

结束语

附录

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐