## 进程和线程

### 进程:

> 进程可理解为是一个正在运行的程序整体
>
> 进程是具有一定独立功能的程序,是操作系统进行资源分配的**基本单位**

### 线程:

> 线程是操作系统进行调度的基本单位



### 进程 vs. 线程

1. 一个程序至少有一个进程,一个进程至少有一个线程

   ## 进程和线程

   ### 进程:

   > 进程可理解为是一个正在运行的程序整体
   >
   > 进程是具有一定独立功能的程序,是操作系统进行资源分配的**基本单位**

   ### 线程:

   > 线程是操作系统进行调度的基本单位

   

   ### 进程 vs. 线程

   1. 一个程序至少有一个进程,一个进程至少有一个线程

   ![file](http://jeff.spring4all.com/Fkj6R64OhpVBeVPd5A9M8_TO6GrB)
   2. 线程比进程划分更细,执行开销更小,并发性更高

   3. 进程是一个实体,拥有独立的资源,而同一进程中的多个线程是共享进程的资源的如下图:
      ![file](http://jeff.spring4all.com/Ft072HRCLQ68lpezDBoSaoRhf2T7)
   4. JVM在单进程中运行,JVM中的线程共享属于该进程的堆,所以几个线程可以同时访问堆中的某个对象,这就导致了线程不安全

   5. 线程在进程中拥有自己的Stack空间,所以一个线程调用方法以及其他局部变量是线程完全的

   ### 总结

   进程和线程是包含关系，但是多任务既可以由多进程实现，也可以由单进程内的多线程实现，还可以混合多进程＋多线程。

   具体采用哪种方式，要考虑到进程和线程的特点。

   和多线程相比，多进程的缺点在于：

   - 创建进程比创建线程开销大，尤其是在Windows系统上；
   - 进程间通信比线程间通信要慢，因为线程间通信就是读写同一个变量，速度很快。

   而多进程的优点在于：

   多进程稳定性比多线程高，因为在多进程的情况下，一个进程崩溃不会影响其他进程，而在多线程的情况下，任何一个线程崩溃会直接导致整个进程崩溃。

   Java语言内置了多线程支持：一个Java程序实际上是一个JVM进程，JVM进程用一个主线程来执行`main()`方法，在`main()`方法内部，我们又可以启动多个线程。此外，JVM还有负责垃圾回收的其他工作线程等。

   因此，对于大多数Java程序来说，我们说多任务，实际上是说如何使用多线程实现多任务。

   和单线程相比，多线程编程的特点在于：多线程经常需要读写共享数据，并且需要同步。例如，播放电影时，就必须由一个线程播放视频，另一个线程播放音频，两个线程需要协调运行，否则画面和声音就不同步。因此，多线程编程的复杂度高，调试更困难。

   Java多线程编程的特点又在于：

   - 多线程模型是Java程序最基本的并发模型；
   - 后续读写网络、数据库、Web开发等都依赖Java多线程模型。

   因此，必须掌握Java多线程编程才能继续深入学习其他内容。

JAVA并发之线程&进程

JAVA多线程中的各种问题剖析

> 首先开始之前 需要提及一下前置章节
>
> 能够更加深入了解本节所讲

1. [JAVA并发之基础概念篇](https://mp.weixin.qq.com/s/b8aX2DAICYQ05i1DI8SAmA)
2. [JAVA并发之进程VS线程篇](https://mp.weixin.qq.com/s/VE1FjX3Iimz21MOOQbWBCw)

首先我们来说一下并发的优点,根据优点特性,引出并发应当注意的安全问题

### 1并发的优点

> 技术在进步，CPU、内存、I/O 设备的性能也在不断提高。但是，始终存在一个核心矛盾：**CPU、内存、I/O 设备存在速度差异**。CPU 远快于内存，内存远快于 I/O 设备。
>
> 根据木桶短板理论可知，一只木桶能装多少水，取决于最短的那块木板。程序整体性能取决于最慢的操作——I/O，即单方面提高 CPU 性能是无效的。

为了合理利用 CPU 的高性能，平衡这三者的速度差异，计算机体系机构、操作系统、编译程序都做出了贡献，主要体现为：

- **CPU 增加了缓存**，以均衡与内存的速度差异；
- **操作系统增加了进程、线程**，以分时复用 CPU，进而均衡 CPU 与 I/O 设备的速度差异；
- **编译程序优化指令执行次序**，使得缓存能够得到更加合理地利用。

其中，进程、线程使得计算机、程序有了并发处理任务的能力，它有`两个重要优点`：

- 提升资源利用率
- 降低程序响应时间

#### 1.1提升资源利用率

![image-20201023145402806](/Users/tengyu/Library/Application Support/typora-user-images/image-20201023145402806.png)

​		从磁盘中读取文件的时候，大部分的 CPU 时间用于等待磁盘去读取数据。在这段时间里，CPU 非常的空闲。它可以做一些别的事情。通过改变操作的顺序，就能够更好的使用 CPU 资源 ,使用并发方式不一定就是磁盘IO,也可以是网络IO和用户输入等,但是不管是哪种IO 都比CPU 和内存IO慢的多.线程并不能提高速度，而是在执行某个耗时的功能时，在还可以做其它的事。多线程使你的程序在处理文件时不必显得已经卡死.

#### 1.2降低程序响应时间

​		为了使程序的响应时间变的更短,使用多线程应用程序也是常见的一种方式将一个单线程应用程序变成多线程应用程序的另一个常见的目的是实现一个响应更快的应用程序。设想一个服务器应用，它在某一个端口监听进来的请求。当一个请求到来时，它去处理这个请求，然后再返回去监听。

服务器的流程如下所述：

```java
public class SingleThreadWebServer {
    public static void main(String[] args) throws IOException{
        ServerSocket socket = new ServerSocket(80);
        while (true) {
            Socket connection = socket.accept();
            handleRequest(connection);
        }
    }
}
```

如果一个请求需要占用大量的时间来处理，在这段时间内新的客户端就无法发送请求给服务端。只有服务器在监听的时候，请求才能被接收。另一种设计是，监听线程把请求传递给工作者线程(worker thread)，然后立刻返回去监听。而工作者线程则能够处理这个请求并发送一个回复给客户端。这种设计如下所述：

```java
public class ThreadPerTaskWebServer {
    public static void main(String[] args) throws IOException {
        ServerSocket socket = new ServerSocket(80);
        while (true) {
            final Socket connection = socket.accept();
            Runnable workerThread = new Runnable() {
                public void run() {
                    handleRequest(connection);　　　　　　　　
                }　　　　
            }; 　　　
         } 　
     } 
}
```

这种方式，服务端线程迅速地返回去监听。因此，更多的客户端能够发送请求给服务端。这个服务也变得响应更快。

桌面应用也是同样如此。如果你点击一个按钮开始运行一个耗时的任务，这个线程既要执行任务又要更新窗口和按钮，那么在任务执行的过程中，这个应用程序看起来好像没有反应一样。相反，任务可以传递给工作者线程（worker thread)。当工作者线程在繁忙地处理任务的时候，窗口线程可以自由地响应其他用户的请求。当工作者线程完成任务的时候，它发送信号给窗口线程。窗口线程便可以更新应用程序窗口，并显示任务的结果。对用户而言，这种具有工作者线程设计的程序显得响应速度更快。

### 2并发带来的安全性问题

并发安全是指 保证程序在并发处理时的结果 符合预期
并发安全需要保证**3个特性**:

**原子性:**通俗讲就是相关操作不会中途被其他线程干扰，一般通过同步机制（加锁：`sychronized`、`Lock`）实现。

**有序性:**保证线程内串行语义，避免指令重排等

**可见性:一个线程修改了某个共享变量，其状态能够立即被其他线程知晓，通常被解释为将线程本地状态反映到主内存上，`volatile` 就是负责保证可见性的**

Ps:对于`volatile`这个关键字,需要单独写一篇文章来讲解,后续更新 请持续关注公众号:`JAVA宝典`

#### 2.1 原子性问题

​		早期,CPU速度比IO操作快很多,一个程序在读取文件时,可将自己标记为"休眠状态"并让出CPU的使用权,等待数据加载到内存后,操作系统会唤醒该进程,唤醒后就有机会重新获得CPU使用权.
​		这些操作会引发进程的切换,不同进程间是不共享内存空间的，所以进程要做任务切换就要切换内存映射地址.
而一个进程创建的所有线程，都是共享一个内存空间的，所以线程做任务切换成本就很低了
所以我们现在提到的`任务切换`都是指`线程切换`

> 高级语言里一条语句,往往需要多个 CPU 指令完成,如:
>
> `count += 1`，至少需要三条 CPU 指令

> - 指令 1：首先，需要把变量 count 从内存加载到 CPU 的寄存器；
> - 指令 2：之后，在寄存器中执行 +1 操作；
> - 指令 3：最后，将结果写入内存（缓存机制导致可能写入的是 CPU 缓存而不是内存）。

**原子性问题出现**:

​		对于上面的三条指令来说，我们假设 count=0，如果线程 A 在指令 1 执行完后做线程切换，线程 A 和线程 B 按照下图的序列执行，那么我们会发现两个线程都执行了 count+=1 的操作，但是得到的结果不是我们期望的 2，而是 1。

![image-20201023161752307](/Users/tengyu/Library/Application Support/typora-user-images/image-20201023161752307.png)

**我们把一个或者多个操作在 CPU 执行的过程中不被中断的特性称为原子性**。CPU 能保证的原子操作是 CPU 指令级别的，而不是高级语言的操作符，这是违背我们直觉的地方。因此，很多时候我们需要在高级语言层面保证操作的原子性。

#### 2.2有序性问题

​		顾名思义，有序性指的是程序按照代码的先后顺序执行。编译器为了优化性能，有时候会改变程序中语句的先后顺序

举个例子:	

​	双重检查创建单例对象,在获取实例 getInstance() 的方法中，我们首先判断 instance 是否为空，如果为空，则锁定 Singleton.class 并再次检查 instance 是否为空，如果还为空则创建 Singleton 的一个实例.

```java
public class Singleton {
  static Singleton instance;
  static Singleton getInstance(){
    if (instance == null) {
      synchronized(Singleton.class) {
        if (instance == null)
          instance = new Singleton();
        }
    }
    return instance;
  }
}
```

​		线程A,B如果同时调用getInstance()方法获取实例,他们会同时检查到instance 为null  ,这时会将Singleton.class进行加锁操作,此时jvm保证只有一个锁上锁成功,另一个线程会等待状态;假设线程A加锁成功,这时线程A会new一个实例之后释放锁,线程B被唤醒,线程B会再次加锁此时加锁成功,线程B检查实例是否为null,会发现已经被实例化,不会再创建另外一个实例.

这段代码和逻辑看上去没有问题,但实际上getInstance()方法还是有问题的,问题在new的操作上,我们认为的new操作应该是:

>1.分配内存
>
>2.在这块内存上初始化Singleton对象
>
>3.将内存地址给instance变量

但是实际jvm优化后的操作是这样的:

>1分配内存
>
>2将地址给instance变量
>
>3在内存上初始化Singleton对象

![image-20201023170219995](/Users/tengyu/Library/Application Support/typora-user-images/image-20201023170219995.png)

优化后会导致 我们这个时候另一个线程访问 instance 的成员变量时获取对象不为null 就结束实例化操作 返回instance 会触发空指针异常。

 #### 2.3可见性问题

> 一个线程对共享变量的修改，另外一个线程能够立刻看到，称为 **可见性**。

现代多核心CPU,每个核心都有自己的缓存,多个线程在不同的CPU核心上执行时,线程操作的是不同的CPU缓存,

![image-20201023202807558](/Users/tengyu/Library/Application Support/typora-user-images/image-20201023202807558.png)

线程不安全的示例

下面的代码，每执行一次 add10K() 方法，都会循环 10000 次 count+=1 操作。在 calc() 方法中我们创建了两个线程，每个线程调用一次 add10K() 方法，我们来想一想执行 calc() 方法得到的结果应该是多少呢？

```java
class Test {
    private static long count = 0;
    private void add10K() {
        int idx = 0;
        while(idx++ < 10000) {
            count += 1;
        }
    }

    public static  long getCount(){
        return count;
    }
    public static void calc() throws InterruptedException {
        final Test test = new Test();
        // 创建两个线程，执行 add() 操作
        Thread th1 = new Thread(()->{
            test.add10K();
        });
        Thread th2 = new Thread(()->{
            test.add10K();
        });
        // 启动两个线程
        th1.start();
        th2.start();
        // 等待两个线程执行结束
        th1.join();
        th2.join();
    }

    public static void main(String[] args) throws InterruptedException {
        Test.calc();
        System.out.println(Test.getCount());
        //运行三次 分别输出 11880 12884 14821
    }
}
```

​		直觉告诉我们应该是 20000，因为在单线程里调用两次 add10K() 方法，count 的值就是 20000，但实际上 calc() 的执行结果是个 10000 到 20000 之间的随机数。为什么呢？

​		我们假设线程 A 和线程 B 同时开始执行，那么第一次都会将 count=0 读到各自的 CPU 缓存里，执行完 count+=1 之后，各自 CPU 缓存里的值都是 1，同时写入内存后，我们会发现内存中是 1，而不是我们期望的 2。之后由于各自的 CPU 缓存里都有了 count 的值，两个线程都是基于 CPU 缓存里的 count 值来计算，所以导致最终 count 的值都是小于 20000 的。这就是缓存的可见性问题。

​		循环 10000 次 count+=1 操作如果改为循环 1 亿次，你会发现效果更明显，最终 count 的值接近 1 亿，而不是 2 亿。如果循环 10000 次，count 的值接近 20000，原因是两个线程不是同时启动的，有一个`时差`。

### 3如何保证并发安全

了解保证并发安全的方法,首先要了解同步是什么:

> 同步是指在多线程并发访问共享数据时,保证共享数据在同一时刻只被一个线程访问

实现保证并发安全有下面3种方式:

1.阻塞同步(悲观锁):

> 阻塞同步也称为互斥同步,是常见并发保证正确性的手段,临界区（Critical Sections）、互斥量（Mutex）和信号量（Semaphore）都是主要的互斥实现方式
>
> 最典型的案例是使用 `synchronized` 或 `Lock` 。
>
> **互斥同步最主要的问题是线程阻塞和唤醒所带来的性能问题**，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施，那就肯定会出现问题。无论共享数据是否真的会出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加锁）、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。

2.非阻塞同步(乐观锁)

> 基于冲突检测的乐观并发策略：先进行操作，如果没有其它线程争用共享数据，那操作就成功了，否则采取补偿措施（不断地重试，直到成功为止）。这种乐观的并发策略的许多实现都不需要将线程阻塞，因此这种同步操作称为非阻塞同步
>
> 乐观锁指令常见的有：
>
> - 测试并设置（Test-amd-Set）
> - 获取并增加（Fetch-and-Increment）
> - 交换（Swap）
> - 比较并交换（CAS）
> - 加载链接、条件存储（Load-linked / Store-Conditional）
>
> Java 典型应用场景：J.U.C 包中的原子类（基于 `Unsafe` 类的 CAS (Compare and swap) 操作）

3.无同步

>要保证线程安全，不一定非要进行同步。同步只是保证共享数据争用时的正确性，如果一个方法本来就不涉及共享数据，那么自然无须同步。
>
>Java 中的 **无同步方案** 有：
>
>- **可重入代码** - 也叫纯代码。如果一个方法，它的 **返回结果是可以预测的**，即只要输入了相同的数据，就能返回相同的结果，那它就满足可重入性，程序可以在被打断处继续执行，且执行结果不受影响,当然也是线程安全的。
>- **线程本地存储** - 使用 **`ThreadLocal` 为共享变量在每个线程中都创建了一个本地副本**，这个副本只能被当前线程访问，其他线程无法访问，那么自然是线程安全的。



### 4总结

​		为了并发的优点 我们选择了多线程,多线程并发给我们带来了好处 也带来了问题,处理这些安全性问题我们选择加锁让共享数据同时只能进入一个线程来保证并发时数据安全,这时加锁也为我们带来了诸多问题 如:死锁,活锁,线程饥饿等问题

下一篇我们将剖析`加锁导致的活跃性问题` 尽请期待



JAVA并发之多线程引发的问题剖析以及如何保证线程安全

首先提及一下前置知识:

> 1.[JAVA并发之基础概念](https://mp.weixin.qq.com/s/b8aX2DAICYQ05i1DI8SAmA) 
> 2.[JAVA并发之进程VS线程](https://mp.weixin.qq.com/s/VE1FjX3Iimz21MOOQbWBCw) 
> 3.[JAVA并发之多线程引发的问题剖析及如何保证线程安全](https://mp.weixin.qq.com/s/q07rwQAGKsxeUxzw01835Q)

​		在前三章我们讨论了`多线程并发`的优点以及如何加锁来处理并发带来的`安全性问题`

​		但是加锁也为我们带来了诸多问题 如:死锁,活锁,线程饥饿等问题 这一章我我们主要处理锁带来的问题.
首先就是最出名的死锁

### 1.死锁(Deadlock)

什么是死锁

![image-20201026192610810](/Users/lty/IdeaProjects/wx_gzh_article/pic/image-20201026192610810-3715871-3715990.png)

> ​		死锁是当线程进入无限期等待状态时发生的情况，因为所请求的锁被另一个线程持有，而另一个线程又等待第一个线程持有的另一个锁 导致互相等待。总结:多个线程互相等待对方释放锁。

例如在现实中的十字路口，锁就像红路灯指示器，一旦锁坏了，就会导致交通瘫痪。
那么该如何避免这个问题呢  

#### 死锁的解决和预防

1.超时释放锁

		>​		顾名思义,这种避免死锁的方式是在尝试获取锁的时候加一个超时时间,这就意味着,如果一个线程在获取锁的门口等待太久这个线程就会放弃这次请求,退还并释放所有已经获得的锁,再在等待一段随机时间后再次尝试,这段时间其他的线程伙伴可以去尝试拿锁.

```java
public interface Lock {
	//自定义异常类
    public static class TimeOutException extends Exception{
        public TimeOutException(String message){
            super(message);
        }
    }
	//无超时锁，可以被打断
    void lock() throws  InterruptedException;
    //超时锁，可以被打断
    void lock(long molls) throws InterruptedException,TimeOutException;
    //解锁
    void unlock();
    //获取当前等待的线程
    Collection<Thread> getBlockedThread();
    //获取当前阻塞的线程数目
    int getBlockSize();
}


```

```java
public class BooleanLock  implements Lock{
    private boolean initValue;
    private Thread currenThread;
    public BooleanLock(){
        this.initValue = false;
    }
    private Collection<Thread> blockThreadCollection = new ArrayList<>();

    @Override
    public synchronized void lock() throws InterruptedException {
        while (initValue){
            blockThreadCollection.add(Thread.currentThread());
            this.wait();
        }
        //表明此时正在用，别人进来就要锁住
        this.initValue = true;
        currenThread = Thread.currentThread();
        blockThreadCollection.remove(Thread.currentThread());//从集合中删除
    }

    @Override
    public synchronized void lock(long mills) throws InterruptedException, TimeOutException {
        if (mills<=0){
            lock();
        }else {
            long hasRemain = mills;
            long endTime = System.currentTimeMillis()+mills;
            while (initValue){
                if (hasRemain<=0)
                    throw new TimeOutException("Time out");
                blockThreadCollection.add(Thread.currentThread());
                hasRemain = endTime-System.currentTimeMillis();
            }
            this.initValue = true;
            currenThread = Thread.currentThread();
        }


    }

    @Override
    public synchronized void unlock() {
        if (currenThread==Thread.currentThread()){
            this.initValue = false; //表明锁已经释放
            Optional.of(Thread.currentThread().getName()+ " release the lock monitor").ifPresent(System.out::println);
            this.notifyAll();
        }
    }

    @Override
    public Collection<Thread> getBlockedThread() {
        return Collections.unmodifiableCollection(blockThreadCollection);
    }

    @Override
    public int getBlockSize() {
        return blockThreadCollection.size();
    }
}


```

```java
public class BlockTest {
    public static void main(String[] args) throws InterruptedException {
    final BooleanLock booleanLock = new BooleanLock();
    // 使用Stream流的方式创建四个线程
        Stream.of("T1","T2","T3","T4").forEach(name->{
            new Thread(()->{
                try {
                    booleanLock.lock(10);
                    Optional.of(Thread.currentThread().getName()+" have the lock Monitor").ifPresent(System.out::println);
                    work();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } catch (Lock.TimeOutException e) {
                    Optional.of(Thread.currentThread().getName()+" time out").ifPresent(System.out::println);
                } finally {
                    booleanLock.unlock();
                }
            },name).start();
        });
    }

  	//如果是需要一直等待就调用 lock()，如果是超时要退出来就调用超时lock(long millo)
    private static void work() throws InterruptedException{
        Optional.of(Thread.currentThread().getName()+" is 		working.....'").ifPresent(System.out::println);
        Thread.sleep(40_000);
    }
}

```

运行:

```java

T1 have the lock Monitor
T1 is working.....
T2 time out
T4 time out
T3 time out

```



2.按顺序加锁

		>按照顺序加锁是一种有效防止死锁的机制,但是这种方式,你需要先知道所有可能用到锁的位置,并对这些锁安排一个顺序

3.死锁检测

		>​		死锁检测是一个更好的死锁预防机制,主要用于超时锁和按顺序加锁不可用的场景每当一个线程获得了锁，会在线程和锁相关的数据结构中（map、graph 等等）将其记下。除此之外，每当有线程请求锁，也需要记录在这个数据结构中。当一个线程请求锁失败时，这个线程可以遍历锁的关系图看看是否有死锁发生。

如果检测出死锁，有两种处理手段：

- 释放所有锁，回退，并且等待一段随机的时间后重试。这个和简单的加锁超时类似，不一样的是只有死锁已经发生了才回退，而不会是因为加锁的请求超时了。虽然有回退和等待，但是如果有大量的线程竞争同一批锁，它们还是会重复地死锁,原因同超时类似，不能从根本上减轻竞争.
- 一个更好的方案是给这些线程设置优先级，让一个（或几个）线程回退，剩下的线程就像没发生死锁一样继续保持着它们需要的锁。如果赋予这些线程的优先级是固定不变的，同一批线程总是会拥有更高的优先级。为避免这个问题，可以在死锁发生的时候设置随机的优先级。

### 2.活锁(Livelock)

什么是活锁

![image-20201026201127219](/Users/lty/IdeaProjects/wx_gzh_article/pic/image-20201026201127219-3715883-3716018.png)

​		死锁是一直死等，活锁他不死等，它会一直执行，但是线程就是不能继续，因为它不断重试相同的操作。换句话说，就是信息处理线程并没有发生阻塞，但是永远都不会前进了,当他们为了彼此间的响应而相互礼让，使得没有一个线程能够继续前进，那么就发生了活锁

#### 避免活锁

​		解决“**活锁**”的方案很简单，谦让时，尝试等待一个随机的时间就可以了。由于等待的时间是随机的，所以同时相撞后再次相撞的概率就很低了。“等待一个随机时间”的方案虽然很简单，却非常有效，Raft 这样知名的分布式一致性算法中也用到了它。

### 3.饥饿

​		什么是饥饿

>- 高优先级线程吞噬所有的低优先级线程的 CPU 时间。
>- 线程被永久堵塞在一个等待进入同步块的状态，因为其他线程总是能在它之前持续地对该同步块进行访问。
>- 线程在等待一个本身(在其上调用 wait())也处于永久等待完成的对象，因为其他线程总是被持续地获得唤醒。

​												 ![image-20201026201620680](/Users/lty/IdeaProjects/wx_gzh_article/pic/image-20201026201620680-3715896.png)

饥饿问题最经典的例子就是哲学家问题。如图所示：有五个哲学家用餐，每个人要活得两把叉子才可以就餐。当 2、4 就餐时，1、3、5 永远无法就餐，只能看着盘中的美食饥饿的等待着。

#### 解决饥饿

Java 不可能实现 100% 的公平性，我们依然可以通过同步结构在线程间实现公平性的提高。

有三种方案：

> - 保证资源充足
> - 公平地分配资源
> - 避免持有锁的线程长时间执行

这三个方案中，方案一和方案三的适用场景比较有限，因为很多场景下，资源的稀缺性是没办法解决的，持有锁的线程执行的时间也很难缩短。倒是方案二的适用场景相对来说更多一些。
		那如何公平地分配资源呢？在并发编程里，主要是使用**公平锁**。所谓公平锁，是一种先来后到的方案，线程的等待是有顺序的，排在等待队列前面的线程会优先获得资源。

### 4.性能问题

​		并发执行一定比串行执行快吗？线程越多执行越快吗？

​		答案是：**并发不一定比串行快**。因为有创建线程和线程`上下文切换`的开销。

### 5.上下文切换

#### 什么是上下文切换？

​		当 CPU 从执行一个线程切换到执行另一个线程时，CPU 需要保存当前线程的本地数据，程序指针等状态，并加载下一个要执行的线程的本地数据，程序指针等。这个开关被称为“上下文切换”。

#### 减少上下文切换的方法

>- 无锁并发编程 - 多线程竞争锁时，会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的 ID 按照 Hash 算法取模分段，不同的线程处理不同段的数据。
>- CAS 算法 - Java 的 Atomic 包使用 CAS 算法来更新数据，而不需要加锁。
>- 使用最少线程 - 避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态。
>- 使用协程 - 在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。

### 6.资源限制

#### 什么是资源限制

​		资源限制是指在进行并发编程时，程序的执行速度受限于计算机硬件资源或软件资源。

#### 资源限制引发的问题

​		在并发编程中，将代码执行速度加快的原则是将代码中串行执行的部分变成并发执行，但是如果将某段串行的代码并发执行，因为受限于资源，仍然在串行执行，这时候程序不仅不会加快执行，反而会更慢，因为增加了上下文切换和资源调度的时间。

#### 如何解决资源限制的问题

​		在资源限制情况下进行并发编程，根据不同的资源限制调整程序的并发度。

>- 对于硬件资源限制，可以考虑使用集群并行执行程序。
>- 对于软件资源限制，可以考虑使用资源池将资源复用。

### 总结

至本章为止,多线程并发的概念篇就结束了,实际操作篇尽情期待
持续关注公众号 `JAVA宝典`

JAVA并发之加锁导致的活跃性问题

> 由于Java面向对象的思想，在JVM中需要大量存储对象，存储时为了实现一些额外的功能，需要在对象中添加一些标记字段用于增强对象功能 。在学习并发编程知识`synchronized`时，我们总是难以理解其实现原理，因为偏向锁、轻量级锁、重量级锁都涉及到对象头，所以了解`java`对象头是我们深入了解`synchronized`的前提条件,以下我们使用`64位JDK示例`



### 1.对象布局的总体结构

### 2.获取一个对象布局实例

1.首先在maven项目中 引入查看对象布局的神器

```xml
		<dependency>
			<groupId>org.openjdk.jol</groupId>
			<artifactId>jol-core</artifactId>
			<version>0.9</version>
		</dependency>
```

2.调用ClassLayout.parseInstance().toPrintable()

```java

public class Main{
    public static void main(String[] args) throws InterruptedException {
        L l = new L();  //new 一个对象 
        System.out.println(ClassLayout.parseInstance(l).toPrintable());//输出 l对象 的布局
    }
}
//对象类
class L{
    private boolean myboolean = true;
}
```

运行后输出:

```java
 OFFSET  SIZE      TYPE DESCRIPTION                               VALUE
      0     4           (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4           (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4           (object header)                           f0 e4 2c 11 (11110000 11100100 00101100 00010001) (288154864)
     12     4           (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
     16     1   boolean L.myboolean                               true
     17     7           (loss due to the next object alignment)
Instance size: 24 bytes
Space losses: 0 bytes internal + 7 bytes external = 7 bytes total
```

对象头所占用的内存大小为`16*8bit=128bit`。如果大家自己动手去打印输出，可能得到的结果是`96bit`，这是因为我关闭了指针压缩。`jdk8`版本是默认开启指针压缩的，可以通过配置`vm`参数关闭指针压缩。关于更多压缩指针访问JAVA文档:[官网](http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html)

```java
关闭指针压缩		-XX:-UseCompressedOops 
```

开启指针压缩之后，再看对象的内存布局:

```java
 OFFSET  SIZE      TYPE DESCRIPTION                               VALUE
      0     4           (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4           (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4           (object header)                           43 c1 00 f8 (01000011 11000001 00000000 11111000) (-134168253)
     12     1   boolean L.myboolean                               true
     13     3           (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 3 bytes external = 3 bytes total
```

- OFFSET：偏移地址，单位字节；
- SIZE：占用的内存大小，单位为字节；
- TYPE DESCRIPTION：类型描述，其中`object header`为对象头；
- VALUE：对应内存中当前存储的值；

> 开启指针压缩可以减少对象的内存使用。因此，开启指针压缩，理论上来讲，大约能节省百分之五十的内存。`jdk8`及以后版本已经默认开启指针压缩，无需配置。

普通的对象获取到的对象头结构为:

```ruby
|--------------------------------------------------------------|
|                     Object Header (128 bits)                 |
|------------------------------------|-------------------------|
|        Mark Word (64 bits)         | Klass pointer (64 bits) |
|------------------------------------|-------------------------|
```

普通对象`压缩后`获取结构:

```java
|--------------------------------------------------------------|
|                     Object Header (96 bits)                  |
|------------------------------------|-------------------------|
|        Mark Word (64 bits)         | Klass pointer (32 bits) |
|------------------------------------|-------------------------|
```



数组对象获取到的对象头结构为:

```ruby
|---------------------------------------------------------------------------------|
|                                 Object Header (128 bits)                        |
|--------------------------------|-----------------------|------------------------|
|        Mark Word(64bits)       | Klass pointer(32bits) |  array length(32bits)  |
|--------------------------------|-----------------------|------------------------|
```

```java
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           6d 01 00 f8 (01101101 00000001 00000000 11111000) (-134217363)
     12     4        (object header)                           05 00 00 00 (00000101 00000000 00000000 00000000) (5)
     16    20    int [I.<elements>                             N/A
     36     4        (loss due to the next object alignment)
Instance size: 40 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
```

### 3.对象头的组成

我们先了解一下，一个JAVA对象的存储结构。在Hotspot虚拟机中，对象在内存中的存储布局分为 3 块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）
在我们刚刚打印的结果中可以这样归类:

```java
 OFFSET  SIZE      TYPE DESCRIPTION                               VALUE
      0     4           (object header)    //markword             01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4           (object header)    //markword             00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4           (object header)   //klass pointer 类元数据 43 c1 00 f8 (01000011 11000001 00000000 11111000) (-134168253)
     12     1   boolean L.myboolean                               true	// Instance Data 对象实际的数据
     13     3           (loss due to the next object alignment)			//Padding 对齐填充数据
```



#### 1.Mark Word

这部分主要用来存储对象自身的运行时数据，如hashcode、gc分代年龄等。`mark word`的位长度为JVM的一个Word大小，也就是说32位JVM的`Mark word`为32位，64位JVM为64位。
为了让一个字大小存储更多的信息，JVM将字的最低两个位设置为标记位，不同标记位下的Mark Word示意如下：

![img](https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy95aWJiT056ZHRGZjBybFdRZmNUWFFHWTdYaWJTZ1JxWW9vM2sxWmljQWg5dEpvclczU2JtTlIzbG9aQ0llUDdGdlNiZUlJMzEyZEY5WmVBTFNpY2tUYnl1cFEvNjQw?x-oss-process=image/format,png)

其中各部分的含义如下：
**lock**:2位的锁状态标记位，由于希望用尽可能少的二进制位表示尽可能多的信息，所以设置了lock标记。该标记的值不同，整个mark word表示的含义不同。
通过倒数三位数 我们可以判断出锁的类型

```c++
enum {  locked_value             	= 0, // 0 00 轻量级锁
         unlocked_value           = 1,// 0 01 无锁
         monitor_value            = 2,// 0 10 重量级锁
         marked_value             = 3,// 0 11 gc标志
         biased_lock_pattern      = 5 // 1 01 偏向锁
  };
```

##### 通过内存信息分析锁状态

写一个synchronized加锁的demo分析锁状态
接着，我们再看一下，使用`synchronized`加锁情况下对象的内存信息，通过对象头分析锁状态。

代码:

```java
public class Main{
    public static void main(String[] args) throws InterruptedException {
        L l = new L();
        Runnable RUNNABLE = () -> {
            while (!Thread.interrupted()) {
                synchronized (l) {
                    String SPLITE_STR = "===========================================";
                    System.out.println(SPLITE_STR);
                    System.out.println(ClassLayout.parseInstance(l).toPrintable());
                    System.out.println(SPLITE_STR);
                }
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        };
        for (int i = 0; i < 3; i++) {
            new Thread(RUNNABLE).start();
        }
    }
}

class L{
    private boolean myboolean = true;
}
```

 

输出:

```java
===========================================
 OFFSET  SIZE      TYPE DESCRIPTION                               VALUE
      0     4           (object header)                           5a 97 02 c1 (01011010 10010111 00000010 11000001) (-1056794790)
      4     4           (object header)                           d7 7f 00 00 (11010111 01111111 00000000 00000000) (32727)
      8     4           (object header)                           43 c1 00 f8 (01000011 11000001 00000000 11111000) (-134168253)
     12     1   boolean L.myboolean                               true
     13     3           (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 3 bytes external = 3 bytes total

===========================================
```

`Mark Word`为0X00007FD7C102975A 对应的2进制为: 0xb00000000 00000000 01111111 11010111 11000001 00000010 10010111 01011010
我们可以看到在第一行object header中 value=5a 对应的2进制为01011010  倒数第三位 为0表示不是偏量锁,后两位为10表示为`重量锁` 

```
enum {  locked_value             	= 0, // 0 00 轻量级锁
         unlocked_value           = 1,// 0 01 无锁
         monitor_value            = 2,// 0 10 重量级锁
         marked_value             = 3,// 0 11 gc标志
         biased_lock_pattern      = 5 // 1 01 偏向锁
  };
```

例子2:

```java
public class Main{
    public static void main(String[] args) throws InterruptedException {
        L l = new L();
        synchronized (l) {
            Thread.sleep(1000);
            System.out.println(ClassLayout.parseInstance(l).toPrintable());
            Thread.sleep(1000);
        }     //轻量锁
    }
}

class L{
    private boolean myboolean = true;
}
```

输出:

```java
 OFFSET  SIZE      TYPE DESCRIPTION                               VALUE
      0     4           (object header)                           f0 18 58 00 (11110000 00011000 01011000 00000000) (5773552)
      4     4           (object header)                           00 70 00 00 (00000000 01110000 00000000 00000000) (28672)
      8     4           (object header)                           43 c1 00 f8 (01000011 11000001 00000000 11111000) (-134168253)
     12     1   boolean L.myboolean                               true
     13     3           (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 3 bytes external = 3 bytes total
```

对应的`mark word`为0x00007000005818f0 对应的2进制为0xb00000000 00000000 01110000 00000000 00000000 01011000 00011000 11110000
根据末尾倒数第三位为0 表示不是偏量锁 倒数后2位为00 表示这是一个轻量锁

```java
enum {  locked_value             	= 0, // 0 00 轻量级锁
         unlocked_value           = 1,// 0 01 无锁
         monitor_value            = 2,// 0 10 重量级锁
         marked_value             = 3,// 0 11 gc标志
         biased_lock_pattern      = 5 // 1 01 偏向锁
  };
```

你可能会有疑问mark word = 0x00007000005818f0是怎么算出来的, 根据前64位的value倒序排列拼成的串就是mark word
例子:

```java
 OFFSET  SIZE      TYPE DESCRIPTION                               VALUE
      0     4           (object header)                           f0 18 58 00 (11110000 00011000 01011000 00000000) (5773552)
      4     4           (object header)                           00 70 00 00 (00000000 01110000 00000000 00000000) (28672)
      8     4           (object header)                           43 c1 00 f8 (01000011 11000001 00000000 11111000) (-134168253)
     12     1   boolean L.myboolean                               true
     13     3           (loss due to the next object alignment)
```

Mark word 串为 前64位倒序排列为:00000000 00000000 01110000 00000000 00000000 01011000 00011000 11110000
转换为16进制为 00007000005818f0

#### 2.Klass Pointer

即对象指向它的元数据的指针，虚拟机通过这个指针来确定是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针(通过句柄池访问)。

> 简单引申一下对象的访问方式，我们创建对象的目的就是为了使用它。所以我们的Java程序在运行时会通过虚拟机栈中本地变量表的reference数据来操作堆上对象。但是reference只是JVM中规范的一个指向对象的引用，那这个引用如何去定位到具体的对象呢？因此，不同的虚拟机可以实现不同的定位方式。主要有两种：句柄池和直接指针。

##### 2.1 使用句柄访问

会在堆中开辟一块内存作为句柄池，句柄中储存了对象实例数据（属性值结构体）的内存地址，访问类型数据的内存地址（类信息，方法类型信息），对象实例数据一般也在heap中开辟，类型数据一般储存在方法区中。

**优点**：reference存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而reference本身不需要改变。
**缺点**：增加了一次指针定位的时间开销。

![image-20201028171451156](./pic/image-20201028171451156.png)

##### 2.2 使用指针访问

指针访问方式指reference中直接储存对象在heap中的内存地址，但对应的类型数据访问地址需要在实例中存储。

**优点**：节省了一次指针定位的开销。
**缺点**：在对象被移动时(如进行GC后的内存重新排列)，reference本身需要被修改。

![image-20201028172114517](pic/image-20201028172114517.png)

总结:

> 通过句柄池访问的话，对象的类型指针是不需要存在于对象头中的，但是目前大部分的虚拟机实现都是采用直接指针方式访问。此外如果对象为JAVA数组的话，那么在对象头中还会存在一部分数据来标识数组长度，否则JVM可以查看普通对象的元数据信息就可以知道其大小，看数组对象却不行

#### 3. 对齐填充字节

> 因为JVM要求java的对象占的内存大小应该是8bit的倍数，所以后面有几个字节用于把对象的大小补齐至8bit的倍数，就不特别介绍了

### 4.JVM升级锁的过程

1，当没有被当成锁时，这就是一个普通的对象，Mark Word记录对象的HashCode，锁标志位是01，是否偏向锁那一位是0。

2，当对象被当做同步锁并有一个线程A抢到了锁时，锁标志位还是01，但是否偏向锁那一位改成1，前23bit记录抢到锁的线程id，表示进入偏向锁状态。

3，当线程A再次试图来获得锁时，JVM发现同步锁对象的标志位是01，是否偏向锁是1，也就是偏向状态，Mark Word中记录的线程id就是线程A自己的id，表示线程A已经获得了这个偏向锁，可以执行同步锁的代码。

4，当线程B试图获得这个锁时，JVM发现同步锁处于偏向状态，但是Mark Word中的线程id记录的不是B，那么线程B会先用CAS操作试图获得锁，这里的获得锁操作是有可能成功的，因为线程A一般不会自动释放偏向锁。如果抢锁成功，就把Mark Word里的线程id改为线程B的id，代表线程B获得了这个偏向锁，可以执行同步锁代码。如果抢锁失败，则继续执行步骤5。

5，偏向锁状态抢锁失败，代表当前锁有一定的竞争，偏向锁将升级为轻量级锁。JVM会在当前线程的线程栈中开辟一块单独的空间，里面保存指向对象锁Mark Word的指针，同时在对象锁Mark Word中保存指向这片空间的指针。上述两个保存操作都是CAS操作，如果保存成功，代表线程抢到了同步锁，就把Mark Word中的锁标志位改成00，可以执行同步锁代码。如果保存失败，表示抢锁失败，竞争太激烈，继续执行步骤6。

6，轻量级锁抢锁失败，JVM会使用自旋锁，自旋锁不是一个锁状态，只是代表不断的重试，尝试抢锁。从JDK1.7开始，自旋锁默认启用，自旋次数由JVM决定。如果抢锁成功则执行同步锁代码，如果失败则继续执行步骤7。

7，自旋锁重试之后如果抢锁依然失败，同步锁会升级至重量级锁，锁标志位改为10。在这个状态下，未抢到锁的线程都会被阻塞。

总结:本章节主要介绍了对象布局包含对象头,对象实例数据,和对齐数据.并且介绍了对象头中包含的信息和解析方法
更多内容请持续关注公众号:`java宝典`



JAVA对象布局之对象头(Object Header)

> [JAVA多线程并发容易引发的问题及如何保证线程安全](https://mp.weixin.qq.com/s/THRpIo9LsWyC-k6Ws36O8g)
> 之前的章节中我们介绍了在并发时,容易引发的问题及如何保证线程安全,本章节我们主讲JAVA并发中的无同步方案: `ThreadLocal`

**无同步方案**:

1.可重入代码:

> **可重入代码：**可以在代码执行的任何时刻中断它，转而去执行另外一段代码，而在控制权返回之后，原来的程序不会出现任何的错误。可重入代码有一些公共的特征，例如不依赖存储在堆上的数据和公用的系统资源、用到的状态量都由参数传入、不调用非可重入的方法等。简而言之：**如果一个方法，它的返回结果是可以预测的，只要输入了相同的数据，就能返回相同的结果，那它就满足可重入性的要求，当然也就是线程安全的。**

2.线程本地存储(ThreadLocal):

> **线程本地存储：**如果一段代码所需要的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程中执行？如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内，这样，即是无同步也能做到避免数据争用。

 

[TOC]

### 1.ThreadLocal  介绍

> 一句话总结:
>
> **`ThreadLocal` 是一个存储在线程本地副本的工具类**,要保证线程安全，不一定非要进行同步。同步只是保证共享数据争用时的正确性，如果一个方法本来就不涉及共享数据，那么自然无须同步。既然是本地存储的，那么就只有当前线程可以访问，自然是线程安全的
>
> ![img](https://img2018.cnblogs.com/blog/1368768/201906/1368768-20190613220434628-1803630402.png)

### 2.ThreadLocal  应用

`ThreadLocal` 的常用方法：

```java
public class ThreadLocal<T> {
    public T get() {}
    public void set(T value) {}
    public void remove() {}
    public static <S> ThreadLocal<S> withInitial(Supplier<? extends S> supplier) {}
}
```

说明:

- `get` - 用于获取 `ThreadLocal` 在当前线程中保存的变量副本。
- `set` - 用于设置当前线程中变量的副本。
- `remove` - 用于删除当前线程中变量的副本。如果此线程局部变量随后被当前线程读取，则其值将通过调用其 `initialValue` 方法重新初始化，除非其值由中间线程中的当前线程设置。 这可能会导致当前线程中多次调用 `initialValue` 方法。
- `initialValue` - 为 ThreadLocal 设置默认的 `get` 初始值，需要重写 `initialValue` 方法 。

用法:

```java
ThreadLocal<String> threadLocal = new ThreadLocal<>();//ThreadLocal对象
threadLocal.set("java宝典");//存储内容
String str = threadLocal.get();//获取内容
```

实例:

```java
public class ThreadLocalTest {
    public static void main(String[] args) {
        ThreadLocal<Boolean> threadLocal = new ThreadLocal<>();
        threadLocal.set(false);//存数据
        printCurrentThread(threadLocal.get());
      
        new Thread(new Runnable() {
            @Override
            public void run() {
                threadLocal.set(true);//存数据
                printCurrentThread(threadLocal.get());
            }
        }, "test1").start();//线程test1
      
        new Thread(new Runnable() {
            @Override
            public void run() {
                threadLocal.set(true);//存数据
                printCurrentThread(threadLocal.get());
            }
        }, "test2").start();//线程test2
    }

    private static void printCurrentThread(boolean b) {
        System.out.println(Thread.currentThread().getName() + ":\t" + b);//打印出线程名与传的boolean值
    }
}

//result:
//main:	false
//test1:	true
//test2:	true
```

### 3.ThreadLocal  源码解析

> ThreadLocal做为数据存储类，那么关键点在于`set`与`get`方法。下面代码比较多,讲解主要在注释内.

```java
public void set(T value) {
  Thread t = Thread.currentThread();//获取当前线程
  ThreadLocalMap map = getMap(t);//获取线程的ThreadLocalMap
  if (map != null)
    map.set(this, value);//给map设置值，键为当前的ThreadLocal，值为传入的value
  else
    createMap(t, value);
}

/**
* getMap方法
*/
ThreadLocalMap getMap(Thread t) {
  return t.threadLocals;//返回传入的线程的ThreadLocalMap
}

/**
* createMap方法
*/
void createMap(Thread t, T firstValue) {
  t.threadLocals = new ThreadLocalMap(this, firstValue);//创建新的ThreadLocalMap并将值传入将线程的threadLocals设置为这个ThreadLocalMap
}

```

```java
public T get() {
  Thread t = Thread.currentThread();//获取当前线程
  ThreadLocalMap map = getMap(t);//获取当前线程的map
  if (map != null) {//如果map不为空
    ThreadLocalMap.Entry e = map.getEntry(this);//获取Entry
    if (e != null) {//Entry不为空
      @SuppressWarnings("unchecked")
      T result = (T)e.value;//获取Entry的值
      return result;//返回获取的值
    }
  }
  return setInitialValue();
}

/**
* setInitialValue方法
*/
private T setInitialValue() {
  T value = initialValue();//初始值
  Thread t = Thread.currentThread();//获取当前线程
  ThreadLocalMap map = getMap(t);//获取当前线程的map
  if (map != null)//map不为空设置默认的值，也就是null
    map.set(this, value);
  else
    createMap(t, value);//map为空新建一个map在存储默认的值
  return value;//返回默认值
}
/**
* initialValue方法
*/
protected T initialValue() {
  return null;
}

```

分析：在调用set方法时获取当前线程，通过获取当前线程的ThreadLocalMap，在map不为空的时候将值存储进去，如果map为空那么新建一个ThreadLocalMap并设置给Thread后存储传入的数据。

通过这部分源码可以看出为什么ThreadLocal只能操作自己线程里的数据，因为这里跟它线程的ThreadLocalMap有关系，再来分析ThreadLocalMap

```java
//存储数据的结构，并且是弱引用
static class Entry extends WeakReference<ThreadLocal<?>> {
  /** 与ThreadLocal关联的值 */
  Object value;

  Entry(ThreadLocal<?> k, Object v) {
    super(k);
    value = v;
  }
}

//table的初始容量，必须是2的幂
private static final int INITIAL_CAPACITY = 16;

//table用于存储数据，长度必须是2的幂
private Entry[] table;

//table中存在的数据的条目数
private int size = 0;

//阀值，用于扩容
private int threshold; // Default to 0

//阀值设置为当前传入的值的2/3倍
private void setThreshold(int len) {
  threshold = len * 2 / 3;
}

//下一个值
private static int nextIndex(int i, int len) {
  return ((i + 1 < len) ? i + 1 : 0);
}

//上一个值
private static int prevIndex(int i, int len) {
  return ((i - 1 >= 0) ? i - 1 : len - 1);
}

//构造函数
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
  table = new Entry[INITIAL_CAPACITY];//初始化数组
  int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
  table[i] = new Entry(firstKey, firstValue);//数据存储进去
  size = 1;//数组里面的数据条目数量设置为1
  setThreshold(INITIAL_CAPACITY);//这是阀值
}

```

```java
private void set(ThreadLocal<?> key, Object value) {

  // We don't use a fast path as with get() because it is at
  // least as common to use set() to create new entries as
  // it is to replace existing ones, in which case, a fast
  // path would fail more often than not.

  Entry[] tab = table;
  int len = tab.length;
  //根据threadLocalHashCode进行一个位运算（取模）得到索引i
  int i = key.threadLocalHashCode & (len-1);
 
  for (Entry e = tab[i];
       e != null;
       e = tab[i = nextIndex(i, len)]) {
    ThreadLocal<?> k = e.get();//获取当前下标Entry的值
    //如果获取的ThreadLocal相同直接替换e的值 *1*
    if (k == key) {
      e.value = value;
      return;
    }
    //如果Entry key对应的k为为null那么清空所有key为null的数据 *2*
    if (k == null) {
      replaceStaleEntry(key, value, i);
      return;
    }
  }
  //如果上述都不满足，直接添加 *3*
  tab[i] = new Entry(key, value);
  int sz = ++size;
  if (!cleanSomeSlots(i, sz) && sz >= threshold)
    rehash();
}
//哈希值
private final int threadLocalHashCode = nextHashCode();

private static final int HASH_INCREMENT = 0x61c88647;
//返回下一个哈希值
private static int nextHashCode() {
  return nextHashCode.getAndAdd(HASH_INCREMENT);
}

```

#### 3.1解决 Hash 冲突

`ThreadLocalMap` 虽然是类似 `Map` 结构的数据结构，但它并没有实现 `Map` 接口。它不支持 `Map` 接口中的 `next` 方法，这意味着 `ThreadLocalMap` 中解决 Hash 冲突的方式并非 **拉链表** 方式。

实际上，**`ThreadLocalMap` 采用线性探测的方式来解决 Hash 冲突**。所谓线性探测，就是根据初始 key 的 hashcode 值确定元素在 table 数组中的位置，如果发现这个位置上已经被其他的 key 值占用，则利用固定的算法寻找一定步长的下个位置，依次判断，直至找到能够存放的位置。

```java
private Entry getEntry(ThreadLocal<?> key) {
  int i = key.threadLocalHashCode & (table.length - 1);
  Entry e = table[i];
  if (e != null && e.get() == key)
    return e;
  else
    return getEntryAfterMiss(key, i, e);
}

private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
  Entry[] tab = table;
  int len = tab.length;

  while (e != null) {
    ThreadLocal<?> k = e.get();
    if (k == key)
      return e;
    if (k == null)
      expungeStaleEntry(i);
    else
      i = nextIndex(i, len);
    e = tab[i];
  }
  return null;
}

```

```java
public void remove() {
  ThreadLocalMap m = getMap(Thread.currentThread());//获取当前线程的ThreadLocalMap
  if (m != null)//如果ThreadLocalMap不为空
    m.remove(this);//调用ThreadLocalMap的remove方法
}

/**
* ThreadLocalMap#remove
*/
private void remove(ThreadLocal<?> key) {
  Entry[] tab = table;
  int len = tab.length;//table的长度
  int i = key.threadLocalHashCode & (len-1);//使用哈希值取模（求余操作）
  for (Entry e = tab[i];
       e != null;
       e = tab[i = nextIndex(i, len)]) {
    if (e.get() == key) {
      e.clear();
      expungeStaleEntry(i);
      return;
    }
  }
}

/**
* ThreadLocalMap.Entry#clear
*/
public void clear() {
  this.referent = null;//值设置为null
}

/**
* ThreadLocal#expungeStaleEntry
*/
private int expungeStaleEntry(int staleSlot) {
  Entry[] tab = table;
  int len = tab.length;

  // expunge entry at staleSlot
  tab[staleSlot].value = null;
  tab[staleSlot] = null;
  size--;

  // Rehash until we encounter null
  Entry e;
  int i;
  for (i = nextIndex(staleSlot, len);
       (e = tab[i]) != null;
       i = nextIndex(i, len)) {
    ThreadLocal<?> k = e.get();
    if (k == null) {
      e.value = null;
      tab[i] = null;
      size--;
    } else {
      int h = k.threadLocalHashCode & (len - 1);
      if (h != i) {
        tab[i] = null;

        // Unlike Knuth 6.4 Algorithm R, we must scan until
        // null because multiple entries could have been stale.
        while (tab[h] != null)
          h = nextIndex(h, len);
        tab[h] = e;
      }
    }
  }
  return i;
}


```

### 4.ThreadLocal 特性

ThreadLocal和Synchronized都是为了解决多线程中相同变量的访问冲突问题，不同的点是

- Synchronized是通过线程等待，牺牲时间来解决访问冲突
- ThreadLocal是通过每个线程单独一份存储空间，牺牲空间来解决冲突，并且相比于Synchronized，ThreadLocal具有线程隔离的效果，只有在线程内才能获取到对应的值，线程外则不能访问到想要的值。

正因为ThreadLocal的线程隔离特性，使他的应用场景相对来说更为特殊一些。在android中Looper、ActivityThread以及AMS中都用到了ThreadLocal。当某些数据是以线程为作用域并且不同线程具有不同的数据副本的时候，就可以考虑采用ThreadLocal。

### 5.4.ThreadLocal 内存泄露问题

`ThreadLocalMap` 的 `Entry` 继承了 `WeakReference`，所以它的 **key （`ThreadLocal` 对象）是弱引用，而 value （变量副本）是强引用**。

- 如果 `ThreadLocal` 对象没有外部强引用来引用它，那么 `ThreadLocal` 对象会在下次 GC 时被回收。
- 此时，`Entry` 中的 key 已经被回收，但是 value 由于是强引用不会被垃圾收集器回收。如果创建 `ThreadLocal` 的线程一直持续运行，那么 value 就会一直得不到回收，产生**内存泄露**。

那么如何避免内存泄漏呢？
方法就是：**使用 `ThreadLocal` 的 `set` 方法后，显示的调用 `remove` 方法** 。

```java
ThreadLocal<String> threadLocal = new ThreadLocal();
try {
    threadLocal.set("xxx");
    // ...
} finally {
    threadLocal.remove();
}
```