多端全栈项目实战：商业级代驾全流程落地KE——下栽
downlaod:
www.ukoou.com/resource/1162/ddqzxmsz
Immutability模式：如何利用不变性解决并发问题？
我们曾经说过，“多个线程同时读写同一共享变量存在并发问题”，这里的必要条件之一是读写，如果只有读，而没有写，是没有并发问题的。
解决并发问题，其实最简单的办法就是让共享变量只有读操作，而没有写操作。这个办法如此重要，以至于被上升到了一种解决并发问题的设计模式：不变性（Immutability）模式。所谓不变性，简单来讲，就是对象一旦被创建之后，状态就不再发生变化。换句话说，就是变量一旦被赋值，就不允许修改了（没有写操作）；没有修改操作，也就是保持了不变性。
快速实现具备不可变性的类
实现一个具备不可变性的类，还是挺简单的。将一个类所有的属性都设置成 final 的，并且只允许存在只读方法，那么这个类基本上就具备不可变性了。更严格的做法是这个类本身也是 final 的，也就是不允许继承。因为子类可以覆盖父类的方法，有可能改变不可变性，所以推荐你在实际工作中，使用这种更严格的做法。
Java SDK 里很多类都具备不可变性，只是由于它们的使用太简单，最后反而被忽略了。例如经常用到的 String 和 Long、Integer、Double 等基础类型的包装类都具备不可变性，这些对象的线程安全性都是靠不可变性来保证的。如果你仔细翻看这些类的声明、属性和方法，你会发现它们都严格遵守不可变类的三点要求：类和属性都是 final 的，所有方法均是只读的。
看到这里你可能会疑惑，Java 的 String 方法也有类似字符替换操作，怎么能说所有方法都是只读的呢？我们结合 String 的源代码来解释一下这个问题，下面的示例代码源自 Java 1.8 SDK，我略做了修改，仅保留了关键属性 value[]和 replace() 方法，你会发现：String 这个类以及它的属性 value[]都是 final 的；而 replace() 方法的实现，就的确没有修改 value[]，而是将替换后的字符串作为返回值返回了。
public final class String {
private final char value[];
// 字符替换
String replace(char oldChar,
char newChar) {
//无需替换，直接返回this
if (oldChar == newChar){
return this;
}
int len = value.length;
int i = -1;
/* avoid getfield opcode */
char[] val = value;
//定位到需要替换的字符位置
while (++i < len) {
if (val[i] == oldChar) {
break;
}
}
//未找到oldChar，无需替换
if (i >= len) {
return this;
}
//创建一个buf[]，这是关键
//用来保存替换后的字符串
char buf[] = new char[len];
for (int j = 0; j < i; j++) {
buf[j] = val[j];
}
while (i < len) {
char c = val[i];
buf[i] = (c == oldChar) ?
newChar : c;
i++;
}
//创建一个新的字符串返回
//原字符串不会发生任何变化
return new String(buf, true);
}
}
通过分析 String 的实现，你可能已经发现了，如果具备不可变性的类，需要提供类似修改的功能，具体该怎么操作呢？做法很简单，那就是创建一个新的不可变对象，这是与可变对象的一个重要区别，可变对象往往是修改自己的属性。
所有的修改操作都创建一个新的不可变对象，你可能会有这种担心：是不是创建的对象太多了，有点太浪费内存呢？是的，这样做的确有些浪费，那如何解决呢？
package com.geekerstar.jvm;
/**
* @author geekerstar
* date: 2019-07-24 09:59
* description:
* <p>
* 栈溢出，栈空间不足——StackOverflowError实例
*/
public class SOFTest {
int depth = 0;
public void sofMethod() {
depth++;
sofMethod();
}
public static void main(String[] args) {
SOFTest test = null;
try {
test = new SOFTest();
test.sofMethod();
} finally {
System.out.println("递归次数：" + test.depth);
}
}
}
并发模拟
Postman：HTTP请求模拟工具
Apache Bench（AB）：Apache附带的工具，测试网站性能
JMeter：Apache组织开发的压力测试工具
postman
\
并发模拟 - CountDownLatch
\
线程安全性
当多个线程访问某个类时，不管运行时环境采用何种调度方式或者这些进程将如何交替执行，并且在主调代码中不需要任何额外的同步或协同，这个类都能表现出正确的行为，那么就称这个类是线程安全的。
体现
- 原子性：提供了互斥访问，同一时刻只能有一个线程来对它进行操作
- 可见性：一个线程对主内存的修改可以及时的被其他线程观察到
- 有序性：一个线程观察其他线程中的指令顺序，由于指令重排序的存在，该观察结果一般杂乱无序
原子性 - Atomic包
- AtomicXXX：CAS、Unsafe.compareAndSwapInt
- AtomicLong、LongAdder
- AtomicReference、AtomicReferenceFieldUpdater
- AtomicStampReference：CAS的ABA问题
原子性 - 锁
- synchronized：依赖JVM
- Lock：依赖特殊的CPU指令，代码实现，ReentrantLock
原子性 - synchronized
- 修饰代码块：大括号括起来的代码，作用于调用的对象
- 修饰方法：整个方法，作用与调用的对象
- 修饰静态方法：整个静态方法，作用于所有对象
- 修饰类：括号括起来的部分，作用于所有对象
原子性-对比
- synchronized:不可中断锁，适合竞争不激烈，可读性好
- Lock：可中断锁，多样化同步，竞争激烈时能维持常态
- Atomic:竞争激烈时能维持常态，比Lock性能好，只能同步一个值
可见性
导致共享变量在线程间不可见的原因：
- 线程交叉执行
- 重排序结合线程交叉执行
- 共享变量更新后的值没有在工作内存与主存间及时更新
可见性-synchronized
JMM关于synchronized的两条规定：
- 线程解锁前，必须把共享变量的最新值刷新到主内存
- 线程加锁时，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新读取最新的值（注意：加锁与解锁是同一把锁）
可见性-volatile
通过加入【内存屏障】和【禁止重排序】优化来实现
- 1、对volatile变量写操作时，会在写操作后加入一条store屏障指令，将本地内存中的共享变量值刷新到主内存
- 2、对volatile变量读操作时，会在读操作前加入一条load屏障指令，从主内存中读取共享变量
