我自己的java大全

线程安全

Java中对<b>String对象</b>进行的操作实际上是一个不断创建并回收对象的过程，因此在运行速度上很慢

而<b>StringBuilder和StringBuffer的对象是变量</b>，对变量的操作是直接对该对象就行更改，因此不会进行反复的创建和回收。所以在运行速度上比较快。

代码

解释：上述代码先创建一个String对象str，并赋值abc给str，然后运行到第三行，JVM会再创建一个新的str对象，并将原有str的值和de加起来再赋值给新的str。而第一个创建的str对象被JVM的垃圾回收机制（GC）回收掉。所以str实际上并没有被更改，即String对象一旦创建就不可更改。<b>所以Java中对String对象进行的操作实际上是一个不断创建并回收对象的过程，因此在运行速度上很慢。</b>而StringBuilder和StringBuffer的对象是变量，对变量的操作是直接对该对象就行更改，因此不会进行反复的创建和回收。所以在运行速度上比较快。

2个对象。s首先会在常量池创建“abc”字符串常量，当new的时候就会在堆内存中创建一个对象，此时会把常量池中的字符串常量拷贝一份副本到给到堆内存中的对象，堆内存中的这个对象就会把地址值赋给s。常量池中对象的地址值和堆内存中对象的地址值是不一样的，s指向的是堆内存中的对象，不是常量池中的对象。此时堆内存中有一个对象，常量池中有一个对象，所以创建了2个对象。查看API，String的有参构造。

Java中有常量优化机制，“a”、“b”、“c”本身就是字符串常量，所以在编译时，"a"+"b"+"c"就是“abc”字符串，所以就在常量池创建了“abc”字符串，当执行s2的时候，此时常量池中已经存在了“abc”，所以==号比较返回true。equals方法比较毫无疑问是true。

s1+"c"中s1不是常量，所以不能用常量优化机制来分析。equals方法比较毫无疑问是true。<br><br>s1和s2会分别在常量池中创创建"ab"、"abc"两个对象<br>s3的时候是字符串串联，API解释如下图。所以s3的时候会在对内存中创建StringBuilder(或者StringBuffer)对象，通过append方法拼接成“abc”对象，此时的“abc”是StringBuilder(或者StringBuffer)类型的，通过调用toString方法转成String对象，此时s3指向的是堆内存中这个String对象<br>s2指向的是常量池中的对象，s3指向的是堆内存中的对象，所以==号比较返回false

因为只有当字符串是不可变的，<b>字符串池才有可能实现</b>。字符串池的实现可以在运行时节约很多heap空间，因为不同的字符串变量都指向池中的同一个字符串。但如果字符串是可变的，那么String&nbsp;interning将不能实现，因为这样的话，如果变量改变了它的值，那么其它指向这个值的变量的值也会一起改变。如果字符串是<b>可变的，那么会引起很严重的安全问题</b>。譬如，数据库的用户名、密码都是以字符串的形式传入来获得数据库的连接，或者在socket编程中，主机名和端口都是以字符串的形式传入。因为字符串是不可变的，所以它的值是不可改变的，否则黑客们可以钻到空子，<font color="#f44336">改变字符串指向的对象的值</font>，造成安全漏洞。<br>因为字符串是不可变的，所以是<b>多线程安全的</b>，同一个字符串实例可以被多个线程共享。这样便不用因为线程安全问题而使用同步。字符串自己便是线程安全的。<br>因为字符串是不可变的，所以在它创建的时候<b>HashCode就被缓存</b>了，不需要重新计算。这就使得字符串很<b>适合作为Map中的键</b>，字符串的处理速度要快过其它的键对象。这就是HashMap中的键往往都使用字符串。

final&nbsp;不可变，赋值与声明同步，此后不可修改。如&nbsp;Integer、String&nbsp;这些不可变类，是借由&nbsp;final&nbsp;完成的修饰。<br>所以，若需要修改其中的内容，必须开辟新的内存空间，这会造成不必要的浪费，也是各种缓存机制存在的必然<br>

有：Byte、Short、Integer、Long、Character

无：Float、Double&nbsp;与&nbsp;Boolean

<b>在对象的内存地址基础上经过特定算法返回一个hash码</b>

特殊情况

<b><font color="#f44336">==</font>判断是不是<font color="#f44336">同一个<br></font>equal判断值是不是一样</b>

为什么重写equal后要重写hashcode

(1)当obj1.equals(obj2)为true时，obj1.hashCode()&nbsp;==&nbsp;obj2.hashCode()必须为true<br>(2)当obj1.hashCode()&nbsp;==&nbsp;obj2.hashCode()为false时，obj1.equals(obj2)必须为false

想要判断两个对象是不是一样？&nbsp; 不能业务代码一个一个属性值判断吧？&nbsp; 重写对象的equal将属性值判断放在对象内部完成

怎么实现深拷贝

<b>String也属于引用类型</b>，String在进行传递的时候也是传递的地址，这个地址是堆中的运行时常量池中的地址，但是<b>因为String具有不可变性</b>，在对对象进行赋值的时候，<b>实际上是新创建了一个对象</b>，而不是在原有地址上进行修改，但是<b>观感就像没有变。</b>

hashmap的put方法

hashmap扩容

hashmap变树<br>

面试题

HashMap线程不安全解析

ConcurrentHashMap线程安全机制

ConcurrentHashMap扩容（比hashmap快）

put

写线程会被阻塞，因为红黑树比较特殊，新写入数据，可能会触发红黑树的自平衡，这就会导致树的结构发生变化，会影响读线程的读取结果！<br>在红黑树上读取数据和写入数据是互斥的，具体原理分析如下：<br><br>我们知道&nbsp;ConcurrentHashMap&nbsp;中的红黑树由&nbsp;TreeBin&nbsp;来代理，TreeBin&nbsp;内部有一个&nbsp;Int&nbsp;类型的&nbsp;state&nbsp;字段。<br>当读线程在读取数据时，会使用&nbsp;CAS&nbsp;的方式将&nbsp;state&nbsp;值&nbsp;+4（表示加了读锁），读取数据完毕后，再使用CAS&nbsp;的方式将&nbsp;state&nbsp;值&nbsp;-4。<br>如果写线程去向红黑树中写入数据时，会先检查&nbsp;state&nbsp;值是否等于&nbsp;0，如果是&nbsp;0，则说明没有读线程在检索数据，这时候可以直接写入数据，写线程也会通过&nbsp;CAS&nbsp;的方式将&nbsp;state&nbsp;字段值设置为&nbsp;1（表示加了写锁）。<br>如果写线程检查&nbsp;state&nbsp;值不是&nbsp;0，这时候就会park()挂起当前线程，使其等待被唤醒。挂起写线程时，写线程会先将&nbsp;state&nbsp;值的第&nbsp;2&nbsp;个&nbsp;bit&nbsp;位设置为&nbsp;1（二进制为&nbsp;10），转换成十进制就是&nbsp;2，表示有写线程等待被唤醒。<br>反过来，当红黑树上有写线程正在执行写入操作，那么如果有新的读线程请求该怎么处理？

而进程由内存空间(代码，数据，进程空间，打开的文件)和一个或多个线程组成。

一个标准的线程由线程ID，当前指令指针PC，寄存器和堆栈组成。

一种逻辑上的概念，并非真实存在的物体，只是为了更好地描述CPU的运作能力。简单地说，就是模拟出的CPU核心数。

JMM规定了<b>所有的变量都存储在主内存（Main&nbsp;Memory）中。每个线程还有自己的工作内存（Working&nbsp;Memory）</b>,线程的工作内存中保存了该线程使用到的变量的主内存的副本拷贝，<b>线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行</b>，而不能直接读写主内存中的变量（volatile变量仍然有工作内存的拷贝，但是由于它特殊的操作顺序性规定，所以看起来如同直接在主内存中读写访问一般）。不同的线程之间也无法直接访问对方工作内存中的变量，线程之间值的传递都需要通过主内存来完成。

原子性(Atomicity)

可见性(Visibility)

有序性(Ordering)

概念

作用

重排序是指编译器和处理器为了优化程序性能而对指令序列进行排序的一种手段<br>

JAVA源代码---&gt;<b>编译器</b>优化的重排序---&gt;<b>指令级</b>并行的重排序---&gt;<b>内存系统</b>的重排序---&gt;最终执行指令

<b>编译器</b>优化的重排序

<b>指令级</b>并行的重排序

<b>内存系统</b>的重排序

可见性问题

有序性问题

编译器的重排序

处理器的重排序

数据依赖性

<b>as-if-serial原则</b>

<b>happens-before原则</b>

<b>as-if-serial原则和happens-before原则的区别</b>

阻止屏障两侧的指令重排序；

它会强制将对缓存的修改操作立即写入主存<br>

如果是写操作，它会导致其他CPU中对应的缓存行无效缓存一致性（窥探技术&nbsp;+&nbsp;MESI协议&nbsp;））

硬件层面的内存屏障

java内存屏障

在每个<b><font color="#f44336">volatile写操作</font></b>前插入<font color="#f44336"><b>StoreStore屏障</b></font>，这样就能让其他线程修改A变量后，把修改的值对当前线程可见，在写操作后<b><font color="#f44336">插入StoreLoad屏障</font></b>，这样就能让其他线程获取A变量的时候，能够获取到已经被当前线程修改的值

在每个<b><font color="#f44336">volatile读操作</font></b>前插入<font color="#f44336"><b>LoadLoad屏障</b></font>，这样就能让当前线程获取A变量的时候，保证其他线程也都能<b>获取到相同的值</b>，这样所有的线程读取的数据就一样了，在读操作<b><font color="#f44336">后插入LoadStore屏障</font></b>；这样就能让当前线程<b>在其他线程修改A变量的值之前</b>，获取到主内存里面A变量的的值。

<b>有序性</b>

<b>可见性</b>

<b>原子性</b>

<b><font color="#f44336">可重入性</font></b>

<b><font color="#f44336">不可中断性</font></b>

其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。

<b>同步代码块时</b>

<b>同步方法时</b>

一个类，开两个线程可以同步

synchronized(this)&nbsp; 锁实例对象

synchronized(类.class)&nbsp;锁类对象

所有对象可同步

当前类class锁被获取，不影响对象锁的获取，两者互不影响。

加减

MARK WORD（标记字段）

CLASS POINT&nbsp;（类型指针）

Monitor

存放类的数据信息，父类的信息

由于虚拟机要求对象起始地址必须是8字节的整数倍，填充数据不是必须存在的，仅仅是为了字节对齐。

大概流程

1.6之后优化了

AQS定义了一套多线程访问共享资源的同步器框架，是一个依赖状态的同步器。AQS定义了很多并发中的行为，比如：<br>阻塞等待队列、共享/独占、公平/非公平、可重入、允许中断

<b>由于AQS维护可一个state,所以上锁和解锁要次数一样，不能用于递归</b>

根据对同步资源处理策略不同，锁在宏观上分为乐观锁与悲观锁，这只是概念上的一种称呼，Java中并没有具体的实现类叫做乐观锁或者悲观锁。

乐观锁

悲观锁

乐观锁

悲观锁

乐观锁

悲观锁

概念

理解

存在的问题

来历

解释

好处

坏处

来历

解释

在&nbsp;Java&nbsp;1.5&nbsp;版本及以上的并发包中，<b><font color="#f44336">也就是&nbsp;java.util.concurrent&nbsp;的包中，里面的原子类基本都是自旋锁的实现。外加AQS。</font></b>

<b>并发不高</b>，避免一直自旋不成功<br><br><b>代码简单</b>，不能太复杂，耗时比较短

使用&nbsp;AtomicReference&nbsp;类提供一个可以原子读写的对象引用变量。

定义一个加锁方法，如果有其他线程已经获取锁，当前线程将进入自旋，如果还是已经持有锁的线程获取锁，那就是重入。

定义一个解锁方法，解锁的话，只有持有锁的线程才能解锁，解锁的逻辑思维将&nbsp;count-1，如果&nbsp;count&nbsp;==&nbsp;0，则是把当前持有锁线程设置为&nbsp;null，彻底释放锁。

公平锁

非公平锁

实现

对比

<b>非公平锁</b>通过插队直接获取锁，减少了一次线程阻塞与唤醒过程，系统<b>整体吞吐量提升</b>。

<b>公平锁不会线程饥饿</b>，非公平锁不能保证等待时间最长的线程优先获取锁。

synchronized&nbsp;锁只能是一种非公平锁；<br><br> ReentrantLock&nbsp;锁则可以通过构造函数指定使用公平锁还是非公平锁（<b>默认是非公平锁</b>）。<br>

可重入锁

不可重入锁

ReentrantLock和NonReentrantLock都继承AQS，<b>AQS中维护了一个同步状态&nbsp;state&nbsp;来计数</b>，state&nbsp;初始值为0，随着占有锁的线程的子流程占据和释放锁，state进行相应增减操作。getState()&nbsp;方法能获取最新的&nbsp;state&nbsp;值。即通过<b>state的累加和最终状态是否是0</b>来实现可重入。

<b>代码递归</b>时持有同一个对象锁，但是<b>第一次递归的代码持有锁了，第二次递归就拿不到</b>，则死锁。

Java&nbsp;中以&nbsp;<b>Reentrant&nbsp;开头</b>命名的锁都是可重入锁，而且&nbsp;JDK&nbsp;提供的所有现成&nbsp;Lock&nbsp;的实现类，包括<b>&nbsp;synchronized&nbsp;关键字锁都是可重入</b>的。<b>不可重入锁需要自己去实现。</b>不可重入锁的使用场景非常非常少。

共享锁&nbsp;&amp;&nbsp;独享锁

读写锁

线程会判断此时持有锁的线程是否就是自己（持有锁的线程ID也在对象头里），线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。

轻量级锁状态下继续锁竞争，没有抢到锁的线程将自旋，即不停地循环判断锁是否能够被成功获取。获取锁的操作，其实就是通过<b>CAS修改</b>对象头里的锁标志位。<b>不会进入阻塞队列中</b>

长时间的自旋操作是非常消耗资源的，一个线程持有锁，其他线程就只能在原地空耗CPU，执行不了任何有效的任务，这种现象叫做忙等（busy-waiting）。如果多个线程用一个锁，但是没有发生锁竞争，或者发生了很轻微的锁竞争，那么synchronized就用轻量级锁，允许短时间的忙等现象。<b>这是一种折衷的想法，短时间的忙等，换取线程在用户态和内核态之间切换的开销。</b>

此忙等是有限度的（有个计数器记录自旋次数，<b>默认允许循环10次，可以通过虚拟机参数更改</b>）

虽然StringBuffer的append是一个同步方法，但是这段程序中的StringBuffer属于一个局部变量，并且不会从该方法中逃逸出去（即StringBuffer&nbsp;sb的引用没有传递到该方法外，不可能被其他线程拿到该引用），所以其实这过程是线程安全的，可以将锁消除。

这里每次调用stringBuffer.append方法都需要加锁和解锁，如果虚拟机检测到有一系列连串的对同一个对象加锁和解锁操作，就会将其合并成一次范围更大的加锁和解锁操作，即在第一次append方法时进行加锁，最后一次append方法结束后进行解锁。

public&nbsp;ThreadPoolExecutor(int&nbsp;corePoolSize,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;int&nbsp;maximumPoolSize,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;long&nbsp;keepAliveTime,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TimeUnit&nbsp;unit,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BlockingQueue&lt;Runnable&gt;&nbsp;workQueue)&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;this(corePoolSize,&nbsp;maximumPoolSize,&nbsp;keepAliveTime,&nbsp;unit,&nbsp;workQueue,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Executors.defaultThreadFactory(),&nbsp;defaultHandler);<br>}<br><br>public&nbsp;ThreadPoolExecutor(int&nbsp;corePoolSize,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;int&nbsp;maximumPoolSize,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;long&nbsp;keepAliveTime,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TimeUnit&nbsp;unit,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BlockingQueue&lt;Runnable&gt;&nbsp;workQueue,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>ThreadFactory&nbsp;threadFactory</b>)&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;this(corePoolSize,&nbsp;maximumPoolSize,&nbsp;keepAliveTime,&nbsp;unit,&nbsp;workQueue,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;threadFactory,&nbsp;defaultHandler);<br>}<br><br>public&nbsp;ThreadPoolExecutor(int&nbsp;corePoolSize,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;int&nbsp;maximumPoolSize,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;long&nbsp;keepAliveTime,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TimeUnit&nbsp;unit,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BlockingQueue&lt;Runnable&gt;&nbsp;workQueue,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>&nbsp;RejectedExecutionHandler&nbsp;handler</b>)&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;this(corePoolSize,&nbsp;maximumPoolSize,&nbsp;keepAliveTime,&nbsp;unit,&nbsp;workQueue,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Executors.defaultThreadFactory(),&nbsp;handler);<br>}<br><br>public&nbsp;ThreadPoolExecutor(int&nbsp;corePoolSize,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;int&nbsp;maximumPoolSize,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;long&nbsp;keepAliveTime,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TimeUnit&nbsp;unit,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BlockingQueue&lt;Runnable&gt;&nbsp;workQueue,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>ThreadFactory&nbsp;threadFactory,</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>&nbsp;RejectedExecutionHandler&nbsp;handler</b>)&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;(corePoolSize&nbsp;&lt;&nbsp;0&nbsp;||<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;maximumPoolSize&nbsp;&lt;=&nbsp;0&nbsp;||<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;maximumPoolSize&nbsp;&lt;&nbsp;corePoolSize&nbsp;||<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;keepAliveTime&nbsp;&lt;&nbsp;0)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;throw&nbsp;new&nbsp;IllegalArgumentException();<br>&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;(workQueue&nbsp;==&nbsp;null&nbsp;||&nbsp;threadFactory&nbsp;==&nbsp;null&nbsp;||&nbsp;handler&nbsp;==&nbsp;null)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;throw&nbsp;new&nbsp;NullPointerException();<br>&nbsp;&nbsp;&nbsp;&nbsp;this.corePoolSize&nbsp;=&nbsp;corePoolSize;<br>&nbsp;&nbsp;&nbsp;&nbsp;this.maximumPoolSize&nbsp;=&nbsp;maximumPoolSize;<br>&nbsp;&nbsp;&nbsp;&nbsp;this.workQueue&nbsp;=&nbsp;workQueue;<br>&nbsp;&nbsp;&nbsp;&nbsp;this.keepAliveTime&nbsp;=&nbsp;unit.toNanos(keepAliveTime);<br>&nbsp;&nbsp;&nbsp;&nbsp;this.threadFactory&nbsp;=&nbsp;threadFactory;<br>&nbsp;&nbsp;&nbsp;&nbsp;this.handler&nbsp;=&nbsp;handler;<br>}

<b>corePoolSize（必需）</b>：核心线程数。即池中<b>一直保持存活的线程数</b>，即使这些线程处于空闲。<br>但是将<font color="#f44336"><b>allowCoreThreadTimeOut</b></font>参数设置为true后，核心线程处于空闲一段时间以上，<b>也会被回收</b>。<br><br><b>maximumPoolSize（必需）</b>：池中允许的最大线程数。当核心线程全部繁忙且任务队列打满之后，线程池会临时追加线程，直到总线程数达到maximumPoolSize这个上限。<br><br><b>keepAliveTime（必需）</b>：线程空闲超时时间。当非核心线程处于空闲状态的时间超过这个时间后，该线程将被回收。<br>将<b>allowCoreThreadTimeOut</b>参数设置为true后，核心线程也会被回收。<br><br><b>unit（必需）</b>：keepAliveTime参数的时间单位。有：TimeUnit.DAYS（天）、TimeUnit.HOURS（小时）、TimeUnit.MINUTES（分钟）、TimeUnit.SECONDS（秒）、TimeUnit.MILLISECONDS（毫秒）、TimeUnit.MICROSECONDS（微秒）、TimeUnit.NANOSECONDS（纳秒）<br><br><b>workQueue（必需）</b>：任务队列，<b><font color="#f44336">采用阻塞队列实现</font></b>。当核心线程全部繁忙时，后续由execute方法提交的Runnable将存放在任务队列中，等待被线程处理。<br><br><b>threadFactory（可选）</b>：线程工厂。指定线程池创建线程的方式。<br><br><b>handler（可选）</b>：拒绝策略。当线程池中线程数达到maximumPoolSize且workQueue打满时，后续提交的任务将被拒绝，handler可以指定用什么方式拒绝任务。<br>

任务队列workQueue

<b>拒绝策略</b>handler

线程工厂threadFactory

runState表示当前线程池的状态，它是一个&nbsp;volatile&nbsp;变量用来保证线程之间的可见性。

RUNNING：当创建线程池后，初始时，线程池处于RUNNING状态；

SHUTDOWN：如果调用了shutdown()方法，则线程池处于SHUTDOWN状态，此时线程池不能够接受新的任务，它会等待所有任务执行完毕；

STOP：如果调用了shutdownNow()方法，则线程池处于STOP状态，此时线程池不能接受新的任务，并且会去尝试终止正在执行的任务；

TIDYING：当所有的任务已终止，ctl记录的”任务数量”为0，线程池会变为TIDYING状态。

TERMINATED：当线程池处于SHUTDOWN或STOP状态，并且所有工作线程已经销毁，任务缓存队列已经清空或执行结束后，线程池被设置为TERMINATED状态。

<b>默认情况下</b>，创建线程池之后，<b>线程池中是没有线程的</b>，需要提交任务之后才会创建线程。

立即初始化线程

shutdown()

shutdownNow()

setCorePoolSize

setMaximumPoolSize

固定容量线程池。其特点是<b>最大线程数就是核心线程数</b>，意味着<b>线程池只能创建核心线程</b>，<b>keepAliveTime为0，即线程执行完任务立即回收</b>。任务队列未指定容量，代表使用默认值Integer.MAX_VALUE。<font color="#f44336"><b>适用于需要控制并发线程的场景。</b></font>

LinkedBlockingQueue无界队列

构造函数的keepAliveTime=0，然后核心线程个数和最大线程个数都限制死了，所以虽然用的是LinkedBlockingQueue无界队列，但是其实不会用到无界的特性，<b>其实是当有界来用</b>。

缓存线程池。<font color="#000000" style=""><b>没有核心线程，普通线程数量为Integer.MAX_VALUE（可以理解为无限</b></font><font color="#000000"><b>）</b></font>，线程闲置60s后回收，任务队列使用SynchronousQueue这种无容量的同步队列。<font color="#f44336"><b>适用于任务量大但耗时低的场景。</b></font>

SynchronousQueue同步队列

单线程线程池。特点是线程池中<b>只有一个线程（核心线程</b>），线程<b>执行完任务立即回收</b>，使用有界阻塞队列（容量未指定，使用默认值Integer.MAX_VALUE）

LinkedBlockingQueue无界队列

核心线程和最大线程都是1，keepAliveTime=0，这个也是拿LinkedBlockingQueue<b>无界队列当有界队列使用</b>。

定时线程池。<b>指定核心线程数量，普通线程数量无限，线程执行完任务立即回收</b>，任务队列为延时阻塞队列。这是一个比较特别的线程池，适用于执行定时或周期性的任务。

DelayQueue延迟队列

因为需要延时，这个使用DelayQueue延迟队列就没有任何毛病

子主题

<b>尽量使用较小的线程池</b>，一般为CPU核心数+1。&nbsp;因为CPU密集型任务使得CPU使用率很高，若开过多的线程数，只能增加上下文切换的次数，因此会带来额外的开销。

<b>可以使用稍大的线程池</b>，一般为2*CPU核心数。&nbsp;IO密集型任务CPU使用率并不高，因此可以让CPU在等待IO的时候去处理别的任务，充分利用CPU时间。

具体情况具体分析，可通过压测分析

从内存回收角度来看java堆可分为：新生代和老生代

从内存分配的角度看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区

概念

虚拟机栈存在的异常<br>

虚拟机栈的生命周期

虚拟机栈的执行

局部变量的复用

如果线程请求的栈的深度大于虚拟机栈的最大深度，就会报堆栈溢出错误&nbsp;**StackOverflowError**&nbsp;（这种错误经常出现在递归中）。Java虚拟机也可以动态扩展，但随着扩展会不断地申请内存，当无法申请足够内存时就会报错&nbsp;**OutOfMemoryError**。

通过参数&nbsp;–XX:SurvivorRatio&nbsp;来设定

JVM&nbsp;每次只会使用&nbsp;<b>Eden&nbsp;和其中的一块&nbsp;Survivor&nbsp;</b>区域来为对象服务，所以无论什么时候，总是有一块&nbsp;Survivor&nbsp;区域是空闲着的

通过参数&nbsp;–XX:NewRatio&nbsp;来指定

<b>新生代中</b>，每次垃圾收集时都发现大批对象死去，只有少量对象存活，便采用了<b>复制算法</b>，只需要<font color="#f44336"><b>付出少量存活对象</b></font>的复制成本就可以完成收集。

<b>老年代中</b>因为对象存活率高、没有额外空间对它进行分配担保，就必须采用<b>“标记-清理”或者“标记-整理”</b>算法。

晋升老年代的<b>年龄是可以设置</b>的。

Minor&nbsp;GC是新生代GC，指的是发生在新生代的垃圾收集动作。由于java对象大都是朝生夕死的，所以<b>Minor&nbsp;GC非常频繁</b>，一般回收速度也比较快。

Major&nbsp;GC是老年代GC，指的是发生在老年代的GC，<b>通常执行Major&nbsp;GC会连着Minor&nbsp;GC一起执行</b>。Major&nbsp;GC的速度要比Minor&nbsp;GC<b>慢的多</b>。

Full&nbsp;GC是清理整个堆空间，包括年轻代和老年代

每个对象在创建的时候，就给这个对象绑定一个计数器。<b>每当有一个引用指向该对象时，计数器加一；每当有一个指向它的引用被删除时，计数器减一。</b>这样，当没有引用指向该对象时，计数器为0就代表该对象死亡

引用计数算法的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法，

很难解决对象之间相互循环引用的问题。

<b>a,&nbsp;b&nbsp;对象可回收，就一定会被回收吗?</b>

1、虚拟机栈（栈帧中的本地变量表）中引用的对象；<b>（局部变量）</b>

2、本地方法栈中JNI（即一般说的<b>Native方法）引用的对象；</b>

3、方法区中<b>常量</b>引用的对象；

4、方法区中类<b>静态属性</b>引用的对象；

该算法将<b>内存平均分成两部分</b>，然后每次只使用其中的一部分，当这部分内存满的时候，将<b>内存中所有存活的对象复制到另一个内存</b>中，然后将之前的内存清空，只使用这部分内存，循环下去。<br>这个算法与标记-整理算法的区别在于，<b>该算法不是在同一个区域复制，</b>而是将所有存活的对象复制到另一个区域内。

在存活对象不多的情况下，性能高，能解决内存碎片和java垃圾回收算法之-标记清除&nbsp;中导致的引用更新问题。

会造成一部分的<b>内存浪费</b>。不过可以根据实际情况，将<b>内存块大小比例适当调整</b>；<br>如果存活对象的<b>数量比较大</b>，复制算法的性能会变得<b>很差</b>。<br>

1、复制算法一般是<b>使用在新生代</b>中，因为新生代中的对象一般都是朝生夕死的，<b>存活对象的数量并不多(</b>98%熬不过第一轮收集<b>)</b>，这样使用复制算法进行拷贝时效率比较高。&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<br>2、每次分配内存只使用Eden和其中一块Survivor。&nbsp;发生垃圾搜集时，&nbsp;将<b><font color="#f44336">Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor</font></b>空间上，&nbsp;然后直接清理掉Eden和已用过的那块Survivor空&nbsp;间;<br>3、不过jvm在应用复制算法时，并不是把内存按照1:1来划分的，这样太浪费内存空间了。一般的jvm都是8:1。也即是说,Eden区:From区:To区域的比例是始终有90%的空间是可以用来创建对象的,而剩下的10%用来存放回收后存活的对象。

为每个对象存储一个标记位，记录对象的状态（活着或是死亡）。<br>分为两个阶段，一个是标记阶段，这个阶段内，<b>为每个对象更新标记位</b>，检查对象是否死亡；<br>第二个阶段是清除阶段，该阶段对<b>死亡的对象进行清除</b>，执行&nbsp;GC&nbsp;操作。

是可以<b>解决循环引用</b>的问题<br><b>必要时才回收</b>(内存不足时)

回收时，<b>应用需要挂起</b>，<b><font color="#f44336">也就是stop&nbsp;the&nbsp;world。</font></b><br>尤其是要扫描的<b>对象比较多</b>的时候标记和清除的<b>效率不高</b>，<br>会造成<b><font color="#f44336">内存碎片</font></b>(会导致明明有内存空间,但是由于不连续,申请稍微大一些的对象无法做到)

该算法一般应用于老年代,因为老年代的对象生命周期比较长。

标记清除算法和标记整理算法非常相同，但是标记整理算法在标记清除算法之上<b><font color="#f44336">解决内存碎片化</font></b>（有些人叫"标记整理算法"为"标记压缩算法"）<br>1、在标记阶段，该算法也将所有对象标记为存活和死亡两种状态；<br>2、不同的是，在第二个阶段，该算法并没有直接对死亡的对象进行清理，而是<b>将所有存活的对象整理一下，放到另一处空间，（则可以整理出连续的大存储空间）</b><br>3、然后把剩下的所有对象全部清除。这样就达到了标记-整理的目的。<br>

解决标记清除算法出现的<b>内存碎片问题</b>，

压缩阶段，<b><font color="#f44336">由于移动了可用对象，需要去更新引用。</font></b>

该算法一般应用于老年代,因为老年代的对象生命周期比较长。

这种算法，根据对象的存活周期的不同将内存划分成几块，新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。可以用抓重点的思路来理解这个算法。<br>新生代对象朝生夕死,对象数量多，只要重点扫描这个区域，那么就可以大大提高垃圾收集的效率。另外老年代对象存储久，无需经常扫描老年代，避免扫描导致的开销。

在新生代，每次垃圾收集器都发现有大批对象死去，只有少量存活，采用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。

而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须“标记清除法或者标记整理算法进行回收。

Serial复制算法

ParNew复制算法

Parallel&nbsp;Scavenge复制算法

Serial/ParNew和Parallel&nbsp;Scavenge对比

Serial&nbsp;Old标记-整理

Parallel&nbsp;Old标记-整理

<font color="#f44336"><b>CMS标记-清除</b></font>

<b><font color="#f44336">G1</font></b>

Serial&nbsp;/&nbsp;Serial&nbsp;Old<br>ParNew&nbsp;/&nbsp;Serial&nbsp;Old<br>Parallel&nbsp;Scavenge&nbsp;/&nbsp;Serial&nbsp;Old<br><br>Serial&nbsp;/&nbsp;CMS<br>ParNew&nbsp;/&nbsp;CMS<br><br>Parallel&nbsp;Scavenge&nbsp;/&nbsp;Parallel&nbsp;Old<br><br>G1<br>

所谓的双亲委派，则是先让父类加载器试图加载该Class，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父加载器，依次递归，如果父加载器可以完成类加载任务，就成功返回；只有父加载器无法完成此加载任务时，才自己去加载。

<b>解决重复加载问题</b>

<b>更加安全，保证核心类不会被篡改</b>

举例

图片缓存框架中，“内存缓存”中的图片是以这种引用来保存，使得JVM在发生OOM之前，可以回收这部分缓存。

在静态内部类中，经常会使用虚引用。例如，一个类发送网络请求，承担callback的静态内部类，则常以虚引用的方式来保存外部类(宿主类)的引用，当外部类需要被JVM回收时，不会因为网络请求没有及时回来，导致外部类不能被回收，引起内存泄漏。

一种引用的get()方法返回总是null，所以，可以想象，在平常的项目开发肯定用的少。

第一步，修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)&nbsp;<br><br>第二步，检查错误日志，查看“OutOfMemory”错误前是否有其它异常或错误。&nbsp;<br><br>第三步，对代码进行走查和分析，找出可能发生内存溢出的位置<br><br>第四步，使用内存查看工具动态查看内存使用情况<br>

static这个关键字使一个变量变为只和这个类相关的类变量，和实例无关。<b>他的生命周期是很长的，贯穿于app的启动到关闭。因此只要用一个static引用一个大对象，就可以泄漏了</b>！举个例子：<br><br>static&nbsp;Activity&nbsp;activity;<br><br>这是最简单粗暴的持有一个activity的引用，这样这个activity退出之后对象并没有被销毁。