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

巴特西

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

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

不可变案例

案例展示

同步锁解决

不可变解决

不可变设计

String类型设计

final 的使用

保护性拷贝

模式之享元

定义

体现

案例

原理之final

设置原理

获得原理

final总结

无状态

无状态概述

结束语

附录

最新文章

热门文章