1.String、StringBuffer和StringBuilder的区别

都是final类，都不允许被继承；

String类长度是不可变的，StringBuffer和StringBuilder类长度是可以改变的；

String 和 StringBuffer：

1、String类型和StringBuffer类型的主要性能区别：String是不可变的对象，因此每次在对String类进行改变的时候都会生成一个新的string对象，然后将指针指向新的string对象，所以经常要改变字符串长度的话不要使用string，因为每次生成对象都会对系统性能产生影响，特别是当内存中引用的对象多了以后，JVM的GC就会开始工作，性能就会降低； 

StringBuffer 和 StringBuilder 的 有3 个区别

区别1：线程安全

StringBuffer：线程安全，StringBuilder：线程不安全。因为 StringBuffer 的所有公开方法都是 synchronized 修饰的，而 StringBuilder 并没有 synchronized 修饰。

StringBuffer 代码片段：

@Override
public synchronized StringBuffer append(String str) {
    toStringCache = null;
    super.append(str);
    return this;
}

区别2：缓冲区

StringBuffer 代码片段：

private transient char[] toStringCache;
 
@Override
public synchronized String toString() {
    if (toStringCache == null) {
        toStringCache = Arrays.copyOfRange(value, 0, count);
    }
    return new String(toStringCache, true);
}

StringBuilder 代码片段：

@Override
public String toString() {
    // Create a copy, don't share the array
    return new String(value, 0, count);
}

可以看出，StringBuffer 每次获取 toString 都会直接使用缓存区的 toStringCache 值来构造一个字符串。

而 StringBuilder 则每次都需要复制一次字符数组，再构造一个字符串。

所以，缓存冲这也是对 StringBuffer 的一个优化吧，不过 StringBuffer 的这个toString 方法仍然是同步的。

区别3：性能

既然 StringBuffer 是线程安全的，它的所有公开方法都是同步的，StringBuilder 是没有对方法加锁同步的，所以毫无疑问，StringBuilder 的性能要远大于 StringBuffer。

总结

所以，StringBuffer 适用于用在多线程操作同一个 StringBuffer 的场景，如果是单线程场合 StringBuilder 更适合。

2.MySQL的索引有几种类型？

按照逻辑分类，索引可分为：

主键索引：一张表只能有一个主键索引，不允许重复，不允许为null；

唯一索引：数据列不允许重复，允许为NULL值，一张表可有多个唯一索引，但是一个唯一索引只能包含一列，比如身份证号码，卡号都可以作为唯一索引；

普通索引：一张表可以创建多个普通索引，一个普通索引可以包含多个字段，允许数据重复，允许NULL值插入；

全文索引：让搜索关键词更高效的一种索引；

按照物理分类，索引可分为：

按照物理分类，索引可分为：

聚集索引：一般是表中的主键索引，如果表中没有显示指定主键，则会选择表中的第一个不允许为NULL的唯一索引， 如果还是没有的画，就采用Innodb存储引擎为每行数据内置的6字节rowid作为聚集索引。每张表只有一个聚集索引， 因为聚集索引的兼职的逻辑顺序决定了表中相应行的物理顺序。聚集索引在精确查找和范围查找方面有良好的性能表 现（相对于普通索引和全表扫描），聚集索引就显得弥足珍贵，聚集索引选择还是要慎重（一般不会让没有语义的自增 id充当聚集索引）； 

* 如果表设置了主键，则主键就是聚簇索引
* 如果表没有主键，则会默认第一个NOT NULL，且唯一（UNIQUE）的列作为聚簇索引
* 以上都没有，则会默认创建一个隐藏的row_id作为聚簇索引

非聚集索引：该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同（非主键的那一列），一个表中可以拥有多个非聚集
索引；

创建主键索引

alter table t add primary key add(`id`)

创建唯一索引

alter table t add unique(`username`)

创建普通索引

alter table t add index index_name(`username`)

创建全文索引

alter table t add fulltext (`username`)

聚簇索引和非聚簇索引（也叫二级索引）的区别

创建聚集索引

1.创建表的时候指定主键（注意：SQL Sever默认主键为聚集索引，也可以指定为非聚集索引，而MySQL里主键就是聚集索引）

create table t1(
    id int primary key,
    name nvarchar(255)
)

非聚集（unclustered）索引。
定义：该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同，一个表中可以拥有多个非聚集索引。
非聚集索引，分成普通索引，唯一索引，全文索引。

使用非聚簇索引，可以直接从索引的节点里获取到查询列的数据。没有建索引的话，则需要二次查询去获取原始数据行的score.

聚集索引与非聚集索引的区别是：叶节点是否存放一整行记录

InnoDB 主键使用的是聚簇索引，MyISAM 不管是主键索引，还是二级索引使用的都是非聚簇索引。

下图形象说明了聚簇索引表(InnoDB)和非聚簇索引(MyISAM)的区别：

1.对于非聚簇索引表来说（右图），表数据和索引是分成两部分存储的，主键索引和二级索引存储上没有任何区别。使用的是B+树作为索引的存储结构，所有的节点都是索引，叶子节点存储的是索引+索引对应的记录的数据。

2.对于聚簇索引表来说（左图），表数据是和主键一起存储的，主键索引的叶结点存储行数据(包含了主键值)，二级索引的叶结点存储行的主键值。使用的是B+树作为索引的存储结构，非叶子节点都是索引关键字，但非叶子节点中的关键字中不存储对应记录的具体内容或内容地址。叶子节点上的数据是主键与具体记录(数据内容)。

二级索引：叶子节点中存储主键值，每次查找数据时，根据索引找到叶子节点中的主键值，根据主键值再到聚簇索引中得到完整的一行记录

聚簇索引的优点

1.当你需要取出一定范围内的数据时，用聚簇索引也比用非聚簇索引好。

2.当通过聚簇索引查找目标数据时理论上比非聚簇索引要快，因为非聚簇索引定位到对应主键时还要多一次目标记录寻址,即多一次I/O。

3.使用覆盖索引扫描的查询可以直接使用页节点中的主键值。

聚簇索引的缺点

1.插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。因此，对于InnoDB表，我们一般都会定义一个自增的ID列为主键。

2.更新主键的代价很高，因为将会导致被更新的行移动。因此，对于InnoDB表，我们一般定义主键为不可更新。

3.二级索引访问需要两次索引查找，第一次找到主键值，第二次根据主键值找到行数据。

二级索引的叶节点存储的是主键值，而不是行指针（非聚簇索引存储的是指针或者说是地址），这是为了减少当出现行移动或数据页分裂时二级索引的维护工作，但会让二级索引占用更多的空间。

4.采用聚簇索引插入新值比采用非聚簇索引插入新值的速度要慢很多，因为插入要保证主键不能重复，判断主键不能重复，采用的方式在不同的索引下面会有很大的性能差距，聚簇索引遍历所有的叶子节点，非聚簇索引也判断所有的叶子节点，但是聚簇索引的叶子节点除了带有主键还有记录值，记录的大小往往比主键要大的多。这样就会导致聚簇索引在判定新记录携带的主键是否重复时进行昂贵的I/O代价。

覆盖索引

覆盖索引（covering index）指一个查询语句的执行只用从索引中就能够取得，不必从数据表中读取。也可以称之为实现了索引覆盖。
如果一个索引包含了（或覆盖了）满足查询语句中字段与条件的数据就叫做覆盖索引。

如何实现覆盖索引

常见的方法是：将被查询的字段，建立到联合索引里去。1、如实现：select id,age from user where age = 10;explain分析：因为age是普通索引，使用到了age索引，通过一次扫描B+树即可查询到相应的结果，这样就实现了覆盖索引

为了实现索引覆盖，需要建组合索引idx_age_name(age,name) 

drop index idx_age on user;
create index idx_age_name on user(`age`,`name`);

explain分析：此时字段age和name是组合索引idx_age_name，查询的字段id、age、name的值刚刚都在索引树上，只需扫描一次组合索引B+树即可，这就是实现了索引覆盖，此时的Extra字段为Using index表示使用了索引覆盖。  

分页查询

例如：select id,age,name from user order by age limit 100,2;因为name字段不是索引，所以在分页查询需要进行回表查询，此时Extra为Using filesort文件排序，查询性能低下。

使用索引覆盖：建组合索引idx_age_name(age,name)

表结构

150多万的数据，这么一个简单的语句：

慢查询日志里居然很多用了1秒的，Explain的结果是：

从Explain的结果可以看出，查询已经使用了索引，但为什么还这么慢？

分析：首先，该语句ORDER BY 使用了Using filesort文件排序，查询效率低；其次，查询字段不在索引上，没有使用覆盖索引，需要通过索引回表查询；也有数据分布的原因。

知道了原因，那么问题就好解决了。

解决方案：由于只需查询uid字段，添加一个联合索引便可以避免回表和文件排序，利用覆盖索引提升查询速度，同时利用索引完成排序。

覆盖索引：SQL只需要通过索引就可以返回查询所需要的数据，而不必通过二级索引查到主键之后再去查询数据。

我们再Explain看一次：

Extra信息已经有'Using Index'，表示已经使用了覆盖索引。经过索引优化之后，线上的查询基本不超过0.001秒。

覆盖索引和联合索引的区别在哪里？

 没有区别，覆盖索引只是特定于具体select语录而言的联合索引。也就是说一个联合索引对于某个select语句，通过索引可以直接获取查询结果，而不再需要回表查询啦，就称该联合索引覆盖了这条select语句。

**最左前缀匹配原则：**在MySQL建立联合索引时会遵守最左前缀匹配原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。

比如索引abc_index:(a,b,c)是a,b,c三个字段的联合索引，下列sql执行时都无法命中索引abc_index；

select * from table where c = '1';
 
select * from table where b ='1' and c ='2';

以下三种情况却会走索引:

select * from table where a = '1';
 
select * from table where a = '1' and b = '2';
 
select * from table where a = '1' and b = '2'  and c='3';

是的，索引abc_index:(a,b,c)，只会在where条件中带有(a)、(a,b)、(a,b,c)的三种类型的查询中使用。其实这里说的有一点歧义，其实当where条件只有(a,c)，(c，a)时也会走，但是只走a字段索引，不会走c字段。

3.什么字段适合建立索引，什么字段不适合建立索引

一、哪些情况下适合建索引

2.  主键自动建立唯一索引

3.  频繁作为查询条件的字段应该创建索引。

4. 经常与其他表进行连接的表，在连接字段上应该建立索引；

5. 经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；

6. 索引应该建在选择性高(字段范围比较大)的字段上；

7. 索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；

8. 复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替：

   A、正确选择复合索引中的主列字段，一般是选择性较好的字段；

   B、复合索引的几个字段是否经常同时以AND方式出现在Where子句中？单字段查询是否极少甚至没有？如果是，则可以建立复合索引；否则考虑单字段索引；

   C、如果复合索引中包含的字段经常单独出现在Where子句中，则分解为多个单字段索引；

   E、如果既有单字段索引，又有这几个字段上的复合索引，一般可以删除复合索引；

   字段选择性

   选择性较低索引 可能带来的性能问题

   索引选择性=索引列唯一值/表记录数；

   选择性越高索引检索价值越高，消耗系统资源越少；选择性越低索引检索价值越低，消耗系统资源越多；

   查询条件含有多个字段时，不要在选择性很低字段上创建索引

   可通过创建组合索引来增强低字段选择性和避免选择性很低字段创建索引带来副作用；

   尽量减少possible_keys，正确索引会提高sql查询速度，过多索引会增加优化器选择索引的代价，不要滥用索引；

二、哪些情况下不适合建索引

1. 频繁进行数据操作的表，不要建立太多的索引；
2. 频繁更新的字段不适合建立索引
3. 表数据可以确定比较少的不需要建索引
4. 数据重复且发布比较均匀的的字段不适合建索引（唯一性太差的字段不适合建立索引），例如性别，真假值
5. 参与列计算的列不适合建索引
6. 删除无用的索引，避免对执行计划造成负面影响；

注意事项：

过多的复合索引，在有单字段索引的情况下，一般都是没有存在价值的；相反，还会降低数据增加删除时的性能，特别是对频繁更新的表来说，负面影响更大。

在对建立索引的时候要对表进行加锁，因此应当注意操作在业务空闲的时候进行。

总的来说，小型表肯定不建索引，
或者数据库记录在亿条数据级以上，还是建议使用非关系型数据库。
还有些特殊字段的数据库，比如BLOB，CLOB字段肯定也不适合建索引。

4.怎么创建多线程，创建多线程有哪几种方法？

1.继承Thread类，重写run方法

2.实现Runnable接口，重写run方法，实现Runnable接口的实现类的实例对象作为Thread构造函数的target

3.通过Callable和FutureTask创建线程

4.通过线程池创建线程

方法1：自己的类extend Thread，并复写run()方法，就可以启动新线程并执行自己定义的run()方法。例如：

public class MyThread extends Thread {
 
    public void run() {
        System.out.println("MyThread.run()");
    }
 
}

在合适的地方启动线程：new MyThread().start();

 方法2：实现一个Runnable接口：

public class MyThread extends OtherClass implements Runnable {
 
    public void run() {
        System.out.println("MyThread.run()");
    }
 
}

为了启动MyThread，需要首先实例化一个Thread，并传入自己的MyThread实例：

MyThread myt = new MyThread();
Thread t = new Thread(myt);
t.start();

事实上，当传入一个Runnable target参数给Thread后，Thread的run()方法就会调用target.run()，参考JDK源代码：

public void run() {
    if (target != null) {
        target.run();
    }
}

 方法3：通过Callable和FutureTask创建线程：

注：1. Runnable和Callable有什么不同？

Runnable和Callable都代表那些要在不同的线程中执行的任务。Runnable从JDK1.0开始就有了，Callable是在 JDK1.5增加的。它们的主要区别是Callable的 call() 方法可以返回值和抛出异常，而Runnable的run()方法没有这些功能。Callable可以返回装载有计算结果的Future对象 

Runnable和Callable的区别

(1) Callable规定（重写）的方法是call()，Runnable规定（重写）的方法是run()。

(2) Callable的任务执行后可返回值，而Runnable的任务是不能返回值的。

(3) call方法可以抛出异常，run方法不可以。

(4) 运行Callable任务可以拿到一个Future对象，表示异步计算的结果。它提供了检查计算是否完成的方法，以等待计算的完成，并检索计算的结果。通过Future对象可以了解任务执行情况，可取消任务的执行，还可获取执行结果。

 方法4：通过线程池创建线程

6.多线程有哪几种状态？不同状态之间是怎么进行转换的？

1. 初始(NEW)：新创建了一个线程对象，但还没有调用start()方法。

2. 运行(RUNNABLE)：Java线程中将就绪（ready）和运行中（running）两种状态笼统的称为“运行”。

线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取CPU的使用权，此时处于就绪状态（ready）。就绪状态的线程在获得CPU时间片后变为运行中状态（running）。

3. 阻塞(BLOCKED)：表示线程阻塞于锁。

4. 等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）。

5. 超时等待(TIMED_WAITING)：该状态不同于WAITING，它可以在指定的时间后自行返回。

6. 终止(TERMINATED)：表示该线程已经执行完毕。

1. 初始状态

实现Runnable接口和继承Thread可以得到一个线程类，new一个实例出来，线程就进入了初始状态。

2.1. 就绪状态

1. 就绪状态只是说你资格运行，调度程序没有挑选到你，你就永远是就绪状态。
2. 调用线程的start()方法，此线程进入就绪状态。
3. 当前线程sleep()方法结束，其他线程join()结束，等待用户输入完毕，某个线程拿到对象锁，这些线程也将进入就绪状态。
4. 当前线程时间片用完了，调用当前线程的yield()方法，当前线程进入就绪状态。
5. 锁池里的线程拿到对象锁后，进入就绪状态。

2.2. 运行中状态

线程调度程序从可运行池中选择一个线程作为当前线程时线程所处的状态。这也是线程进入运行状态的唯一一种方式。

3. 阻塞状态

阻塞状态是线程阻塞在进入synchronized关键字修饰的方法或代码块(获取锁)时的状态。

4. 等待

处于这种状态的线程不会被分配CPU执行时间，它们要等待被显式地唤醒，否则会处于无限期等待的状态。

5. 超时等待

处于这种状态的线程不会被分配CPU执行时间，不过无须无限期等待被其他线程显示地唤醒，在达到一定时间后它们会自动唤醒。

6. 终止状态

当线程的run()方法完成时，或者主线程的main()方法完成时，我们就认为它终止了。这个线程对象也许是活的，但是，它已经不是一个单独执行的线程。线程一旦终止了，就不能复生。 在一个终止的线程上调用start()方法，会抛出java.lang.IllegalThreadStateException异常。 

7. 为什么要用线程池，怎么创建线程池？四种线程池的用法分析

那先要明白什么是线程池

线程池是指在初始化一个多线程应用程序过程中创建一个线程集合，然后在需要执行新的任务时重用这些线程而不是新建一个线程。

使用线程池的好处

线程池加快了线程的创建时间，由于线程池中的线程已经准备好，应用程序可以直接拿来使用，

1、new Thread的弊端

执行一个异步任务你还只是如下new Thread吗？

new Thread(new Runnable() {
 
    @Override
    public void run() {
        // TODO Auto-generated method stub
        }
    }
).start();

那你就out太多了，new Thread的弊端如下：

a. 每次new Thread新建对象性能差。
b. 线程缺乏统一管理，可能无限制新建线程，相互之间竞争，及可能占用过多系统资源导致死机或oom。
c. 缺乏更多功能，如定时执行、定期执行、线程中断。

相比new Thread，Java提供的四种线程池的好处在于：

a. 重用存在的线程，减少对象创建、消亡的开销，性能佳。
b. 可有效控制最大并发线程数，提高系统资源的使用率，同时避免过多资源竞争，避免堵塞。
c. 提供定时执行、定期执行、单线程、并发数控制等功能。

2、Java 线程池

Java通过Executors提供四种线程池，分别为：

newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。

newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。

newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。

newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。

(1)newCachedThreadPool：

创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。示例代码如下：

ExecutorService cachedThreadPool = Executors.newCachedThreadPool();
    for (int i = 0; i < 10; i++) {
        final int index = i;
    try {
        Thread.sleep(index * 1000);
    } 
        catch (InterruptedException e) {
            e.printStackTrace();
    }
 
cachedThreadPool.execute(new Runnable() {
 
@Override
public void run() {
    System.out.println(index);
}
});
}

线程池为无限大，当执行第二个任务时第一个任务已经完成，会复用执行第一个任务的线程，而不用每次新建线程。

(2)newFixedThreadPool：

创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。示例代码如下：

ExecutorService fixedThreadPool = Executors.newFixedThreadPool(3);
    for (int i = 0; i < 10; i++) {
    final int index = i;
 
    fixedThreadPool.execute(new Runnable() {
 
@Override
public void run() {
try {
    System.out.println(index);
    Thread.sleep(2000);
} catch (InterruptedException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
    }
}
});
}

(3)newScheduledThreadPool：

创建一个定长线程池，支持定时及周期性任务执行。延迟执行示例代码如下：

ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(5);
 scheduledThreadPool.schedule(new Runnable() {
 
@Override
public void run() {
    System.out.println("delay 3 seconds");
}
}, 3, TimeUnit.SECONDS);

表示延迟3秒执行。

定期执行示例代码如下：

scheduledThreadPool.scheduleAtFixedRate(new Runnable() {
 
@Override
public void run() {
    System.out.println("delay 1 seconds, and excute every 3 seconds");
}
}, 1, 3, TimeUnit.SECONDS);

表示延迟1秒后每3秒执行一次。

ScheduledExecutorService比Timer更安全，功能更强大

(4)newSingleThreadExecutor：

创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。示例代码如下：

ExecutorService singleThreadExecutor = Executors.newSingleThreadExecutor();
for (int i = 0; i < 10; i++) {
final int index = i;
singleThreadExecutor.execute(new Runnable() {
 
@Override
public void run() {
    try {
        System.out.println(index);
    Thread.sleep(2000);
} catch (InterruptedException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
        }
}
    });
}

结果依次输出，相当于顺序执行各个任务。

现行大多数GUI程序都是单线程的。Android中单线程可用于数据库操作，文件操作，应用批量安装，应用批量删除等不适合并发但可能IO阻塞性及影响UI线程响应的操作。

1.corePoolSize：the number of threads to keep in the pool, even if they are idle, unless {@code allowCoreThreadTimeOut} is set

（核心线程数大小：不管它们创建以后是不是空闲的。线程池需要保持 corePoolSize 数量的线程，除非设置了 allowCoreThreadTimeOut。）

2.maximumPoolSize：the maximum number of threads to allow in the pool。

（最大线程数：线程池中最多允许创建 maximumPoolSize 个线程。）

3.keepAliveTime：when the number of threads is greater than the core, this is the maximum time that excess idle threads will wait for new tasks before terminating 

（存活时间：如果经过 keepAliveTime 时间后，超过核心线程数的线程还没有接受到新的任务，那就回收。）

4.unit：the time unit for the {@code keepAliveTime} argument

（keepAliveTime 的时间单位。）

5.workQueue：the queue to use for holding tasks before they are executed. This queue will hold only the {@code Runnable} tasks submitted by the {@code execute} method。 

（存放待执行任务的队列：当提交的任务数超过核心线程数大小后，再提交的任务就存放在这里。它仅仅用来存放被 execute 方法提交的 Runnable 任务。所以这里就不要翻译为工作队列了，好吗？不要自己给自己挖坑。）

6.threadFactory：the factory to use when the executor creates a new thread。

（线程工程：用来创建线程工厂。比如这里面可以自定义线程名称，当进行虚拟机栈分析时，看着名字就知道这个线程是哪里来的，不会懵逼。）

7.handler ：the handler to use when execution is blocked because the thread bounds and queue capacities are reached。

（拒绝策略：当队列里面放满了任务、最大线程数的线程都在工作时，这时继续提交的任务线程池就处理不了，应该执行怎么样的拒绝策略。）

• corePoolSize：核心线程数

• 核心线程会一直存活，及时没有任务需要执行

• 当线程数小于核心线程数时，即使有线程空闲，线程池也会优先创建新线程处理

• 设置allowCoreThreadTimeout=true（默认false）时，核心线程会超时关闭

• queueCapacity：任务队列容量（阻塞队列）

• 当核心线程数达到最大时，新任务会放在队列中排队等待执行

• keepAliveTime：线程空闲时间

• 当线程空闲时间达到keepAliveTime时，线程会退出，直到线程数量=corePoolSize

• 如果allowCoreThreadTimeout=true，则会直到线程数量=0

• allowCoreThreadTimeout：允许核心线程超时

• rejectedExecutionHandler：任务拒绝处理器

• 两种情况会拒绝处理任务：

• 当线程数已经达到maxPoolSize，切队列已满，会拒绝新任务

• 当线程池被调用shutdown()后，会等待线程池里的任务执行完毕，再shutdown。如果在调用shutdown()和线程池真正shutdown之间提交任务，会拒绝新任务

• 线程池会调用rejectedExecutionHandler来处理这个任务。如果没有设置默认是AbortPolicy，会抛出异常

• ThreadPoolExecutor类有几个内部实现类来处理这类情况：

• AbortPolicy 丢弃任务，抛运行时异常

• CallerRunsPolicy 执行任务

• DiscardPolicy 忽视，什么都不会发生

• DiscardOldestPolicy 从队列中踢出最先进入队列（最后一个执行）的任务

• 实现RejectedExecutionHandler接口，可自定义处理器

线程池的作用：

线程池作用就是限制系统中执行线程的数量。

根据系统的环境情况，可以自动或手动设置线程数量，达到运行的最佳效果；少了浪费了系统资源，多了造成系统拥挤效率不高。用线程池控制线程数量，其他线程排 队等候。一个任务执行完毕，再从队列的中取最前面的任务开始执行。若队列中没有等待进程，线程池的这一资源处于等待。当一个新任务需要运行时，如果线程池 中有等待的工作线程，就可以开始运行了；否则进入等待队列。 

为什么要用线程池:

1.减少了创建和销毁线程的次数，每个工作线程都可以被重复利用，可执行多个任务。

2.可以根据系统的承受能力，调整线程池中工作线线程的数目，防止因为消耗过多的内存，而把服务器累趴下(每个线程需要大约1MB内存，线程开的越多，消耗的内存也就越大，最后死机)。

Java里面线程池的顶级接口是Executor，但是严格意义上讲Executor并不是一个线程池，而只是一个执行线程的工具。真正的线程池接口是ExecutorService。

比较重要的几个类：

ExecutorService： 真正的线程池接口。

ScheduledExecutorService： 能和Timer/TimerTask类似，解决那些需要任务重复执行的问题。

ThreadPoolExecutor： ExecutorService的默认实现。

ScheduledThreadPoolExecutor： 继承ThreadPoolExecutor的ScheduledExecutorService接口实现，周期性任务调度的类实现。

要配置一个线程池是比较复杂的，尤其是对于线程池的原理不是很清楚的情况下，很有可能配置的线程池不是较优的，因此在Executors类里面提供了一些静态工厂，生成一些常用的线程池。

1.newSingleThreadExecutor

创建一个单线程的线程池。这个线程池只有一个线程在工作，也就是相当于单线程串行执行所有任务。如果这个唯一的线程因为异常结束，那么会有一个新的线程来替代它。此线程池保证所有任务的执行顺序按照任务的提交顺序执行。

2.newFixedThreadPool

创建固定大小的线程池。每次提交一个任务就创建一个线程，直到线程达到线程池的最大大小。线程池的大小一旦达到最大值就会保持不变，如果某个线程因为执行异常而结束，那么线程池会补充一个新线程。

3.newCachedThreadPool

创建一个可缓存的线程池。如果线程池的大小超过了处理任务所需要的线程，

那么就会回收部分空闲（60秒不执行任务）的线程，当任务数增加时，此线程池又可以智能的添加新线程来处理任务。此线程池不会对线程池大小做限制，线程池大小完全依赖于操作系统（或者说JVM）能够创建的最大线程大小。

4.newScheduledThreadPool

创建一个大小无限的线程池。此线程池支持定时以及周期性执行任务的需求。

实例代码

一、固定大小的线程池，newFixedThreadPool：

package app.executors;  
 
import java.util.concurrent.Executors;  
import java.util.concurrent.ExecutorService;  
 
/** 
 * Java线程：线程池 
 *  
 * @author xiho
 */  
public class Test {  
    public static void main(String[] args) {  
        // 创建一个可重用固定线程数的线程池  
        ExecutorService pool = Executors.newFixedThreadPool(5);  
        // 创建线程  
        Thread t1 = new MyThread();  
        Thread t2 = new MyThread();  
        Thread t3 = new MyThread();  
        Thread t4 = new MyThread();  
        Thread t5 = new MyThread();  
        // 将线程放入池中进行执行  
        pool.execute(t1);  
        pool.execute(t2);  
        pool.execute(t3);  
        pool.execute(t4);  
        pool.execute(t5);  
        // 关闭线程池  
        pool.shutdown();  
    }  
}  
 
class MyThread extends Thread {  
    @Override  
    public void run() {  
        System.out.println(Thread.currentThread().getName() + "正在执行。。。");  
    }  
} 

输出结果：

pool-1-thread-1正在执行。。。  
pool-1-thread-3正在执行。。。  
pool-1-thread-4正在执行。。。  
pool-1-thread-2正在执行。。。  
pool-1-thread-5正在执行。。。  

改变ExecutorService pool = Executors.newFixedThreadPool(5)中的参数：ExecutorService pool = Executors.newFixedThreadPool(2)，输出结果是：

pool-1-thread-1正在执行。。。  
pool-1-thread-1正在执行。。。  
pool-1-thread-2正在执行。。。  
pool-1-thread-1正在执行。。。  
pool-1-thread-2正在执行。。。  

 从以上结果可以看出，newFixedThreadPool的参数指定了可以运行的线程的最大数目，超过这个数目的线程加进去以后，不会运行。其次，加入线程池的线程属于托管状态，线程的运行不受加入顺序的影响。

二、单任务线程池，newSingleThreadExecutor：

仅仅是把上述代码中的ExecutorService pool = Executors.newFixedThreadPool(2)改为ExecutorService pool = Executors.newSingleThreadExecutor();

输出结果：

pool-1-thread-1正在执行。。。  
pool-1-thread-1正在执行。。。  
pool-1-thread-1正在执行。。。  
pool-1-thread-1正在执行。。。  
pool-1-thread-1正在执行。。。  

可以看出，每次调用execute方法，其实最后都是调用了thread-1的run方法。

三、可变尺寸的线程池，newCachedThreadPool：

与上面的类似，只是改动下pool的创建方式：ExecutorService pool = Executors.newCachedThreadPool();

输出结果：

pool-1-thread-1正在执行。。。  
pool-1-thread-2正在执行。。。  
pool-1-thread-4正在执行。。。  
pool-1-thread-3正在执行。。。  
pool-1-thread-5正在执行。。。

这种方式的特点是：可根据需要创建新线程的线程池，但是在以前构造的线程可用时将重用它们。

四、延迟连接池，newScheduledThreadPool：

public class TestScheduledThreadPoolExecutor {
 
    public static void main(String[] args) {
 
        ScheduledThreadPoolExecutor exec = new ScheduledThreadPoolExecutor(1);
 
        exec.scheduleAtFixedRate(new Runnable() {//每隔一段时间就触发异常
 
                      @Override
 
                      publicvoid run() {
 
                           //throw new RuntimeException();
 
                           System.out.println("================");
 
                      }
 
                  }, 1000, 5000, TimeUnit.MILLISECONDS);
 
        exec.scheduleAtFixedRate(new Runnable() {//每隔一段时间打印系统时间，证明两者是互不影响的
 
                      @Override
 
                      publicvoid run() {
 
                           System.out.println(System.nanoTime());
 
                      }
 
                  }, 1000, 2000, TimeUnit.MILLISECONDS);
 
    }
 
}

输出结果：

================
 
8384644549516
 
8386643829034
 
8388643830710
 
================
 
8390643851383
 
8392643879319
 
8400643939383

//引入ScheduledExecutorService做延时任务
ScheduledExecutorService service = Executors.newScheduledThreadPool(50);
 
//发布时间减去当前时间做为延迟时间
long delay = pushTime.getTime() - System.currentTimeMillis();
 
//调用schedule api
//public ScheduledFuture<?> schedule(Runnable command,long delay, TimeUnit unit);
//生成延时线程、延时时间、延时时间单位
service.schedule(() -> videoService.publish(vid), delay, TimeUnit.MILLISECONDS);

3.线程池核心设计与实现

 1.总体设计

Java中的线程池核心实现类是ThreadPoolExecutor，本章基于JDK 1.8的源码来分析Java线程池的核心设计与实现。我们首先来看一下ThreadPoolExecutor的UML类图，了解下ThreadPoolExecutor的继承关系。

ThreadPoolExecutor实现的顶层接口是Executor，顶层接口Executor提供了一种思想：将任务提交和任务执行进行解耦。用户无需关注如何创建线程，如何调度线程来执行任务，用户只需提供Runnable对象，将任务的运行逻辑提交到执行器(Executor)中，由Executor框架完成线程的调配和任务的执行部分。ExecutorService接口增加了一些能力：（1）扩充执行任务的能力，补充可以为一个或一批异步任务生成Future的方法；（2）提供了管控线程池的方法，比如停止线程池的运行。AbstractExecutorService则是上层的抽象类，将执行任务的流程串联了起来，保证下层的实现只需关注一个执行任务的方法即可。最下层的实现类ThreadPoolExecutor实现最复杂的运行部分，ThreadPoolExecutor将会一方面维护自身的生命周期，另一方面同时管理线程和任务，使两者良好的结合从而执行并行任务。 

ThreadPoolExecutor是如何运行，如何同时维护线程和执行任务的呢？其运行机制如下图所示：

线程池在内部实际上构建了一个生产者消费者模型，将线程和任务两者解耦，并不直接关联，从而良好的缓冲任务，复用线程。线程池的运行主要分成两部分：任务管理、线程管理。任务管理部分充当生产者的角色，当任务提交后，线程池会判断该任务后续的流转：（1）直接申请线程执行该任务；（2）缓冲到队列中等待线程执行；（3）拒绝该任务。线程管理部分是消费者，它们被统一维护在线程池内，根据任务请求进行线程的分配，当线程执行完任务后则会继续获取新的任务去执行，最终当线程获取不到任务的时候，线程就会被回收。 

任务缓冲

任务缓冲模块是线程池能够管理任务的核心部分。线程池的本质是对任务和线程的管理，而做到这一点最关键的思想就是将任务和线程两者解耦，不让两者直接关联，才可以做后续的分配工作。线程池中是以生产者消费者模式，通过一个阻塞队列来实现的。阻塞队列缓存任务，工作线程从阻塞队列中获取任务。

阻塞队列(BlockingQueue)是一个支持两个附加操作的队列。这两个附加的操作是：在队列为空时，获取元素的线程会等待队列变为非空。当队列满时，存储元素的线程会等待队列可用。阻塞队列常用于生产者和消费者的场景，生产者是往队列里添加元素的线程，消费者是从队列里拿元素的线程。阻塞队列就是生产者存放元素的容器，而消费者也只从容器里拿元素。 

下图中展示了线程1往阻塞队列中添加元素，而线程2从阻塞队列中移除元素：

使用不同的队列可以实现不一样的任务存取策略。在这里，我们可以再介绍下阻塞队列的成员：

阻塞队列的最长使用的例子就是生产者消费者模式,也是各种实现生产者消费者模式方式中首选的方式。

任务拒绝

任务拒绝模块是线程池的保护部分，线程池有一个最大的容量，当线程池的任务缓存队列已满，并且线程池中的线程数目达到maximumPoolSize时，就需要拒绝掉该任务，采取任务拒绝策略，保护线程池。

拒绝策略是一个接口，其设计如下：

public interface RejectedExecutionHandler {
    void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
}

用户可以通过实现这个接口去定制拒绝策略，也可以选择JDK提供的四种已有拒绝策略，其特点如下：

如何设置参数

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler) {
    ...
}

• 默认值
• corePoolSize=1
• queueCapacity=Integer.MAX_VALUE
• maxPoolSize=Integer.MAX_VALUE
• keepAliveTime=60s
• allowCoreThreadTimeout=false
• rejectedExecutionHandler=AbortPolicy()

这个应该是最重要的参数了，所以如何合理的设置它十分重要。

核心线程会一直存活，及时没有任务需要执行。

当线程数小于核心线程数时，即使有线程空闲，线程池也会优先创建新线程处理。
设置allowCoreThreadTimeout=true（默认false）时，核心线程会超时关闭。
如何设置好的前提我们要很清楚的知道CPU密集型和IO密集型的区别。

(1)、CPU密集型

CPU密集型也叫计算密集型，指的是系统的硬盘、内存性能相对CPU要好很多，此时，系统运作大部分的状况是CPU Loading 100%，CPU要读/写I/O(硬盘/内存)，I/O在很短的时间就可以完成，而CPU还有许多运算要处理，CPU Loading 很高。

在多重程序系统中，大部分时间用来做计算、逻辑判断等CPU动作的程序称之CPU bound。例如一个计算圆周率至小数点一千位以下的程序，在执行的过程当中绝大部分时间用在三角函数和开根号的计算，便是属于CPU bound的程序。

CPU bound的程序一般而言CPU占用率相当高。这可能是因为任务本身不太需要访问I/O设备，也可能是因为程序是多线程实现因此屏蔽掉了等待I/O的时间。

(2)、IO密集型

IO密集型指的是系统的CPU性能相对硬盘、内存要好很多，此时，系统运作，大部分的状况是CPU在等I/O (硬盘/内存) 的读/写操作，此时CPU Loading并不高。

I/O bound的程序一般在达到性能极限时，CPU占用率仍然较低。这可能是因为任务本身需要大量I/O操作，而pipeline做得不是很好，没有充分利用处理器能力。

好了，了解完了以后我们就开搞了。

(3)、先看下机器的CPU核数，然后在设定具体参数：

自己测一下自己机器的核数

System.out.println(Runtime.getRuntime().availableProcessors());

即CPU核数 = Runtime.getRuntime().availableProcessors()

(4)、分析下线程池处理的程序是CPU密集型还是IO密集型

CPU密集型：corePoolSize = CPU核数 + 1

IO密集型：corePoolSize = CPU核数 * 2

• 如何来设置

• 需要根据几个值来决定

• tasks ：每秒的任务数，假设为500~1000

• taskcost：每个任务花费时间，假设为0.1s

• responsetime：系统允许容忍的最大响应时间，假设为1s

• 做几个计算

• corePoolSize = 每秒需要多少个线程处理？

• threadcount = tasks/(1/taskcost) =tasks*taskcout = (5001000)*0.1 = 50100 个线程。corePoolSize设置应该大于50

• 根据8020原则，如果80%的每秒任务数小于800，那么corePoolSize设置为80即可

• queueCapacity = (coreSizePool/taskcost)*responsetime

• 计算可得 queueCapacity = 80/0.1*1 = 80。意思是队列里的线程可以等待1s，超过了的需要新开线程来执行

• 切记不能设置为Integer.MAX_VALUE，这样队列会很大，线程数只会保持在corePoolSize大小，当任务陡增时，不能新开线程来执行，响应时间会随之陡增。

• maxPoolSize = (max(tasks)- queueCapacity)/(1/taskcost)

• 计算可得 maxPoolSize = (1000-80)/10 = 92

• （最大任务数-队列容量）/每个线程每秒处理能力 = 最大线程数

• rejectedExecutionHandler：根据具体情况来决定，任务不重要可丢弃，任务重要则要利用一些缓冲机制来处理

• keepAliveTime和allowCoreThreadTimeout采用默认通常能满足

• 以上都是理想值，实际情况下要根据机器性能来决定。如果在未达到最大线程数的情况机器cpu load已经满了，则需要通过升级硬件（呵呵）和优化代码，降低taskcost来处理。

四、线程池队列的选择

workQueue - 当线程数目超过核心线程数时用于保存任务的队列。主要有3种类型的BlockingQueue可供选择：无界队列，有界队列和同步移交。从参数中可以看到，此队列仅保存实现Runnable接口的任务。

这里再重复一下新任务进入时线程池的执行策略：

当正在运行的线程小于corePoolSize，线程池会创建新的线程。 

当大于corePoolSize而任务队列未满时，就会将整个任务塞入队列。 

当大于corePoolSize而且任务队列满时，并且小于maximumPoolSize时，就会创建新额线程执行任务。

 当大于maximumPoolSize时，会根据handler策略处理线程。

1、无界队列

队列大小无限制，常用的为无界的LinkedBlockingQueue，使用该队列作为阻塞队列时要尤其当心，当任务耗时较长时可能会导致大量新任务在队列中堆积最终导致OOM。阅读代码发现，Executors.newFixedThreadPool 采用就是 LinkedBlockingQueue，而博主踩到的就是这个坑，当QPS很高，发送数据很大，大量的任务被添加到这个无界LinkedBlockingQueue 中，导致cpu和内存飙升服务器挂掉。

当然这种队列，maximumPoolSize 的值也就无效了。当每个任务完全独立于其他任务，即任务执行互不影响时，适合于使用无界队列；例如，在 Web 页服务器中。这种排队可用于处理瞬态突发请求，当命令以超过队列所能处理的平均数连续到达时，此策略允许无界线程具有增长的可能性。

2、有界队列

当使用有限的 maximumPoolSizes 时，有界队列有助于防止资源耗尽，但是可能较难调整和控制。常用的有两类，一类是遵循FIFO原则的队列如ArrayBlockingQueue，另一类是优先级队列如PriorityBlockingQueue。PriorityBlockingQueue中的优先级由任务的Comparator决定。 

使用有界队列时队列大小需和线程池大小互相配合，线程池较小有界队列较大时可减少内存消耗，降低cpu使用率和上下文切换，但是可能会限制系统吞吐量。

3、同步移交队列

如果不希望任务在队列中等待而是希望将任务直接移交给工作线程，可使用SynchronousQueue作为等待队列。SynchronousQueue不是一个真正的队列，而是一种线程之间移交的机制。要将一个元素放入SynchronousQueue中，必须有另一个线程正在等待接收这个元素。只有在使用无界线程池或者有饱和策略时才建议使用该队列。 

8.Threadlocal

ThreadLocal是什么

ThreadLocal是一个关于创建线程局部变量的类。

通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。而使用ThreadLocal创建的变量只能被当前线程访问，其他线程则无法访问和修改。

学习Java中常用的开源框架，Mybatis、Hibernate中设计到线程通过数据库连接对象Connection，对其数据进行操作，都会使用ThreadLocal类来保证Java多线程程序访问和数据库数据的一致性问题。就想深入了解一下ThreadLocal类是怎样确保线程安全的！详解如下： 

一、对其ThreadLocal类的大致了解

 ThreadLocal ，也叫线程本地变量，可能很多朋友都知道ThreadLocal为变量在每个线程中都创建了所使用的的变量副本。使用起来都是在线程的本地工作内存中操作，并且提供了set和get方法来访问拷贝过来的变量副本。底层也是封装了ThreadLocalMap集合类来绑定当前线程和变量副本的关系，各个线程独立并且访问安全！

public class DBUtil {
	//创建一个存储数据库连接对象的ThreadLocal线程本地变量
	private static ThreadLocal<Connection> tl = new ThreadLocal<Connection>();
 
	static{
		try {
			//注册驱动
			DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
		} catch (SQLException e) {
			e.printStackTrace();
		}
	}
	
	/*
	 * 获取数据库的连接对象
	 */
	public static Connection getConnected(){
		Connection conn = null;
		conn = tl.get();		//第一步：从ThreadLocal对象当中去获取
		if(conn == null){		//若没有获取到，原始方法获取
			try {
				conn = DriverManager.getConnection("jdbc:oracle:thin:@192.168.122.1:1521/xe","store","store_password");
				//获取连接对象以后，都设置为默认手动提交
				conn.setAutoCommit(false);	
				//第二部：将连接对象放入对应的ThreadLocal泛型对象tl当中(进而绑定到使用它的线程对象上)
				tl.set(conn);
			} catch (SQLException e) {
				e.printStackTrace();
			}
		}
		return conn;
	}
 
	/*
	 * 关闭数据库的连接，并删除对应的ThreadLocal中的对象
	 */
	public static void closeConnection(){
		Connection conn = null;
		conn = tl.get();		//第三步：使用完毕，再次获取对象
		if(conn != null){
			tl.remove();		//第四步：线程操作数据库完毕，移除
			try {
				conn.close();
			} catch (SQLException e) {
				e.printStackTrace();
			}
		}
	}
}

上述例子中使用ThreadLocal类来绑定对应线程和Connection之间的关系，确保访问数据库数据的安全性问题；大家想象一下，如果没有使用ThreadLocal类来绑定，那么多个线程同时进入getConnected()方法，有可能获取的是同一个Connection对象，导致线程不安全问题！ 

Global && Local

上面的两个修饰看似矛盾，实则不然。

• Global 意思是在当前线程中，任何一个点都可以访问到ThreadLocal的值。
• Local 意思是该线程的ThreadLocal只能被该线程访问，一般情况下其他线程访问不到。

用法简介

创建，支持泛型

ThreadLocal<String> mStringThreadLocal = new ThreadLocal<>();

set方法

mStringThreadLocal.set("droidyue.com");

get方法

mStringThreadLocal.get();

完整的使用示例

private void testThreadLocal() {
    Thread t = new Thread() {
        ThreadLocal<String> mStringThreadLocal = new ThreadLocal<>();
 
        @Override
        public void run() {
            super.run();
            mStringThreadLocal.set("droidyue.com");
            mStringThreadLocal.get();
        }
    };
 
    t.start();
}

ThreadLocal初始值

为ThreadLocal设置默认的get初始值，需要重写initialValue方法，下面是一段代码，我们将默认值修改成了线程的名字

ThreadLocal<String> mThreadLocal = new ThreadLocal<String>() {
    @Override
    protected String initialValue() {
      return Thread.currentThread().getName();
    }
};

Android中的应用

在Android中，Looper类就是利用了ThreadLocal的特性，保证每个线程只存在一个Looper对象。

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

如何实现

为了更好的掌握ThreadLocal，我认为了解其内部实现是很有必要的，这里我们以set方法从起始看一看ThreadLocal的实现原理。

下面是ThreadLocal的set方法，大致意思为

• 首先获取当前线程

• 利用当前线程作为句柄获取一个ThreadLocalMap的对象

• 如果上述ThreadLocalMap对象不为空，则设置值，否则创建这个ThreadLocalMap对象并设置值

源码如下

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}

 下面是一个利用Thread对象作为句柄获取ThreadLocalMap对象的代码

ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}

上面的代码获取的实际上是Thread对象的threadLocals变量，可参考下面代码

class Thread implements Runnable {
    /* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
 
    ThreadLocal.ThreadLocalMap threadLocals = null;
}

而如果一开始设置，即ThreadLocalMap对象未创建，则新建ThreadLocalMap对象，并设置初始值。

void createMap(Thread t, T firstValue) {
    t.threadLocals = new ThreadLocalMap(this, firstValue);
}

 总结：实际上ThreadLocal的值是放入了当前线程的一个ThreadLocalMap实例中，所以只能在本线程中访问，其他线程无法访问。

对象存放在哪里

在Java中，栈内存归属于单个线程，每个线程都会有一个栈内存，其存储的变量只能在其所属线程中可见，即栈内存可以理解成线程的私有内存。而堆内存中的对象对所有线程可见。堆内存中的对象可以被所有线程访问。

问：那么是不是说ThreadLocal的实例以及其值存放在栈上呢？

其实不是，因为ThreadLocal实例实际上也是被其创建的类持有（更顶端应该是被线程持有）。而ThreadLocal的值其实也是被线程实例持有。

它们都是位于堆上，只是通过一些技巧将可见性修改成了线程可见。

真的只能被一个线程访问么

既然上面提到了ThreadLocal只对当前线程可见，是不是说ThreadLocal的值只能被一个线程访问呢？

使用InheritableThreadLocal可以实现多个线程访问ThreadLocal的值。

如下，我们在主线程中创建一个InheritableThreadLocal的实例，然后在子线程中得到这个InheritableThreadLocal实例设置的值。

private void testInheritableThreadLocal() {
    final ThreadLocal threadLocal = new InheritableThreadLocal();
    threadLocal.set("droidyue.com");
    Thread t = new Thread() {
        @Override
        public void run() {
            super.run();
            Log.i(LOGTAG, "testInheritableThreadLocal =" + threadLocal.get());
        }
    };
 
    t.start();
}

上面的代码输出的日志信息为

I/MainActivity( 5046): testInheritableThreadLocal =droidyue.com

 使用InheritableThreadLocal可以将某个线程的ThreadLocal值在其子线程创建时传递过去。因为在线程创建过程中，有相关的处理逻辑。

//Thread.java
 private void init(ThreadGroup g, Runnable target, String name,
                      long stackSize, AccessControlContext acc) {
        //code goes here
        if (parent.inheritableThreadLocals != null)
            this.inheritableThreadLocals =
                ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
        /* Stash the specified stack size in case the VM cares */
        this.stackSize = stackSize;
 
        /* Set thread ID */
        tid = nextThreadID();
}

上面代码就是在线程创建的时候，复制父线程的inheritableThreadLocals的数据。

会导致内存泄露么

有网上讨论说ThreadLocal会导致内存泄露，原因如下

• 首先ThreadLocal实例被线程的ThreadLocalMap实例持有，也可以看成被线程持有。
• 如果应用使用了线程池，那么之前的线程实例处理完之后出于复用的目的依然存活
• 所以，ThreadLocal设定的值被持有，导致内存泄露。

上面的逻辑是清晰的，可是ThreadLocal并不会产生内存泄露，因为ThreadLocalMap在选择key的时候，并不是直接选择ThreadLocal实例，而是ThreadLocal实例的弱引用。

static class ThreadLocalMap {
 
/**
* The entries in this hash map extend WeakReference, using
* its main ref field as the key (which is always a
* ThreadLocal object).  Note that null keys (i.e. entry.get()
* == null) mean that the key is no longer referenced, so the
* entry can be expunged from table.  Such entries are referred to
* as "stale entries" in the code that follows.
*/
    static class Entry extends WeakReference<ThreadLocal<?>> {
        /** The value associated with this ThreadLocal. */
        Object value;
 
        Entry(ThreadLocal<?> k, Object v) {
            super(k);
            value = v;
        }
    }
}

 所以实际上从ThreadLocal设计角度来说是不会导致内存泄露的。关于弱引用，了解更多，请访问译文：理解Java中的弱引用

使用场景

• 实现单个线程单例以及单个线程上下文信息存储，比如交易id等

• 实现线程安全，非线程安全的对象使用ThreadLocal之后就会变得线程安全，因为每个线程都会有一个对应的实例

• 承载一些线程相关的数据，避免在方法中来回传递参数

注意：Android的ThreadLocal与Java实现略有不同，但是原理是一致的。

案例

对于 Java Web 应用而言，Session 保存了很多信息。很多时候需要通过 Session 获取信息，有些时候又需要修改 Session 的信息。一方面，需要保证每个线程有自己单独的 Session 实例。另一方面，由于很多地方都需要操作 Session，存在多方法共享 Session 的需求。如果不使用 ThreadLocal，可以在每个线程内构建一个 Session实例，并将该实例在多个方法间传递，如下所示。

public class SessionHandler {
 
  @Data
  public static class Session {
    private String id;
    private String user;
    private String status;
  }
 
  public Session createSession() {
    return new Session();
  }
 
  public String getUser(Session session) {
    return session.getUser();
  }
 
  public String getStatus(Session session) {
    return session.getStatus();
  }
 
  public void setStatus(Session session, String status) {
    session.setStatus(status);
  }
 
  public static void main(String[] args) {
    new Thread(() -> {
      SessionHandler handler = new SessionHandler();
      Session session = handler.createSession();
      handler.getStatus(session);
      handler.getUser(session);
      handler.setStatus(session, "close");
      handler.getStatus(session);
    }).start();
  }
}

该方法是可以实现需求的。但是每个需要使用 Session 的地方，都需要显式传递 Session 对象，方法间耦合度较高。

这里使用 ThreadLocal 重新实现该功能如下所示。

public class SessionHandler {
 
  public static ThreadLocal<Session> session = ThreadLocal.<Session>withInitial(() -> new Session());
 
  @Data
  public static class Session {
    private String id;
    private String user;
    private String status;
  }
 
  public String getUser() {
    return session.get().getUser();
  }
 
  public String getStatus() {
    return session.get().getStatus();
  }
 
  public void setStatus(String status) {
    session.get().setStatus(status);
  }
 
  public static void main(String[] args) {
    new Thread(() -> {
      SessionHandler handler = new SessionHandler();
      handler.getStatus();
      handler.getUser();
      handler.setStatus("close");
      handler.getStatus();
    }).start();
  }
}

使用 ThreadLocal 改造后的代码，不再需要在各个方法间传递 Session 对象，并且也非常轻松的保证了每个线程拥有自己独立的实例。

如果单看其中某一点，替代方法很多。比如可通过在线程内创建局部变量可实现每个线程有自己的实例，使用静态变量可实现变量在方法间的共享。但如果要同时满足变量在线程间的隔离与方法间的共享，ThreadLocal再合适不过。

9.Redis的5种基本数据结构

• String: 字符串
• Hash: 散列
• List: 列表
• Set: 集合
• Sorted Set: 有序集合

redis是单线程还是多线程的

1. 为什么说redis能够快速执行

(1) 绝大部分请求是纯粹的内存操作（非常快速）

(2) 采用单线程,避免了不必要的上下文切换和竞争条

(3) 非阻塞IO - IO多路复用 注：怎么实现的非阻塞io

2. redis的内部实现

内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间 这3个条件不是相互独立的，特别是第一条，如果请求都是耗时的，采用单线程吞吐量及性能可想而知了。应该说redis为特殊的场景选择了合适的技术方案。

3. Redis关于线程安全问题

redis实际上是采用了线程封闭的观念，把任务封闭在一个线程，自然避免了线程安全问题，不过对于需要依赖多个redis操作的复合操作来说，依然需要锁，而且有可能是分布式锁。

4. Redis淘汰机制(Eviction policies)

首先，需要设置最大内存限制

maxmemory 100mb

选择策略

maxmemory-policy noeviction

解释： 

noeviction:默认策略，不淘汰，如果内存已满，添加数据是报错。

 allkeys-lru:在所有键中，选取最近最少使用的数据抛弃。

 volatile-lru:在设置了过期时间的所有键中，选取最近最少使用的数据抛弃。 

allkeys-random: 在所有键中，随机抛弃。 

volatile-random: 在设置了过期时间的所有键，随机抛弃。 

volatile-ttl:在设置了过期时间的所有键，抛弃存活时间最短的数据。 

4. Redis 持久化

Redis虽然是一种内存型数据库，一旦服务器进程退出，数据库的数据就会丢失，为了解决这个问题Redis提供了两种持久化的方案，将内存中的数据保存到磁盘中，避免数据的丢失。

RDB持久化

redis提供了RDB持久化的功能，这个功能可以将redis在内存中的的状态保存到硬盘中，它可以手动执行，也可以再redis.conf中配置，定期执行。

RDB持久化产生的RDB文件是一个经过压缩的二进制文件，这个文件被保存在硬盘中，redis可以通过这个文件还原数据库当时的状态

RDB的创建与载入

RDB文件可以通过两个命令来生成：

• SAVE：阻塞redis的服务器进程，直到RDB文件被创建完毕。
• BGSAVE：派生(fork)一个子进程来创建新的RDB文件，记录接收到BGSAVE当时的数据库状态，父进程继续处理接收到的命令，子进程完成文件的创建之后，会发送信号给父进程，而与此同时，父进程处理命令的同时，通过轮询来接收子进程的信号。

而RDB文件的载入一般情况是自动的，redis服务器启动的时候，redis服务器再启动的时候如果检测到RDB文件的存在，那么redis会自动载入这个文件。

如果服务器开启了AOF持久化，那么服务器会优先使用AOF文件来还原数据库状态。

RDB是通过保存键值对来记录数据库状态的，采用copy on write的模式，每次都是全量的备份。

自动保存间隔

BGSAVE可以在不阻塞主进程的情况下完成数据的备份。可以通过redis.conf中设置多个自动保存条件，只要有一个条件被满足，服务器就会执行BGSAVE命令。

# 以下配置表示的条件：
# 服务器在900秒之内被修改了1次
save 900 1
# 服务器在300秒之内被修改了10次
save 300 10
# 服务器在60秒之内被修改了10000次
save 60 10000

AOF持久化

AOF持久化（Append-Only-File），与RDB持久化不同，AOF持久化是通过保存Redis服务器锁执行的写状态来记录数据库的。

具体来说，RDB持久化相当于备份数据库状态，而AOF持久化是备份数据库接收到的命令，所有被写入AOF的命令都是以redis的协议格式来保存的。

在AOF持久化的文件中，数据库会记录下所有变更数据库状态的命令，除了指定数据库的select命令，其他的命令都是来自client的，这些命令会以追加(append)的形式保存到文件中。

服务器配置中有一项appendfsync，这个配置会影响服务器多久完成一次命令的记录：

• always：将缓存区的内容总是即时写到AOF文件中。

• everysec：将缓存区的内容每隔一秒写入AOF文件中。

• no ：写入AOF文件中的操作由操作系统决定，一般而言为了提高效率，操作系统会等待缓存区被填满，才会开始同步数据到磁盘。

redis默认实用的是everysec。

redis在载入AOF文件的时候，会创建一个虚拟的client，把AOF中每一条命令都执行一遍，最终还原回数据库的状态，它的载入也是自动的。在RDB和AOF备份文件都有的情况下，redis会优先载入AOF备份文件

AOF文件可能会随着服务器运行的时间越来越大，可以利用AOF重写的功能，来控制AOF文件的大小。AOF重写功能会首先读取数据库中现有的键值对状态，然后根据类型使用一条命令来替代前的键值对多条命令。

AOF重写功能有大量写入操作，所以redis才用子进程来处理AOF重写。这里带来一个新的问题，由于处理重新的是子进程，这样意味着如果主线程的数据在此时被修改，备份的数据和主库的数据将会有不一致的情况发生。因此redis还设置了一个AOF重写缓冲区，这个缓冲区在子进程被创建开始之后开始使用，这个期间，所有的命令会被存两份，一份在AOF缓存空间，一份在AOF重写缓冲区，当AOF重写完成之后，子进程发送信号给主进程，通知主进程将AOF重写缓冲区的内容添加到AOF文件中。

相关配置

#AOF 和 RDB 持久化方式可以同时启动并且无冲突。  
#如果AOF开启，启动redis时会加载aof文件，这些文件能够提供更好的保证。 
appendonly yes
 
# 只增文件的文件名称。（默认是appendonly.aof）  
# appendfilename appendonly.aof 
#redis支持三种不同的写入方式：  
#  
# no:不调用，之等待操作系统来清空缓冲区当操作系统要输出数据时。很快。  
# always: 每次更新数据都写入仅增日志文件。慢，但是最安全。
# everysec: 每秒调用一次。折中。
appendfsync everysec  
 
# 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入.官方文档建议如果你有特殊的情况可以配置为'yes'。但是配置为'no'是最为安全的选择。
no-appendfsync-on-rewrite no  
 
# 自动重写只增文件。  
# redis可以自动盲从的调用‘BGREWRITEAOF’来重写日志文件，如果日志文件增长了指定的百分比。  
# 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100  
# 当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

对比

• AOF更安全，可将数据及时同步到文件中，但需要较多的磁盘IO，AOF文件尺寸较大，文件内容恢复相对较慢， 也更完整。

• RDB持久化，安全性较差，它是正常时期数据备份及 master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。

1.Redis中的redisObject对象

redis中并没有直接使用以上所说的各种数据结构来实现键值数据库，而是基于一种对象，对象底层再间接的引用上文所说的具体的数据结构。

结构如下图：

*ptr属性指向了对象的底层数据结构，而这些数据结构由encoding属性决定。

之所以由encoding属性来决定对象的底层数据结构，是为了实现同一对象类型，支持不同的底层实现。这样就能在不同场景下，使用不同的底层数据结构，进而极大提升Redis的灵活性和效率。

字符串

其中：embstr和raw都是由SDS动态字符串构成的。唯一区别是：raw是分配内存的时候，redisobject和 sds 各分配一块内存，而embstr是redisobject和raw在一块儿内存中。

列表

hash

set

zset

Redis是使用C编写的，内部实现了一个struct结构体redisObject对象，

通过结构体来模仿面向对象编程的“多态”，作为一个底层的数据支持，redisObject代码：

/*
 * Redis 对象
 */
typedef struct redisObject {
    // 类型
    unsigned type:4;
    // 对齐位
    unsigned notused:2;
    // 编码方式
    unsigned encoding:4;
    // LRU 时间（相对于 server.lruclock）
    unsigned lru:22;
    // 引用计数
    int refcount;
    // 指向对象的值
    void *ptr;
} robj;

其中type、encoding、ptr3个属性分别表示：

type：redisObject的类型，字符串、列表、集合、有序集、哈希表

encoding：底层实现结构，字符串、整数、跳跃表、压缩列表等

ptr：实际指向保存值的数据结构

如果一个 redisObject 的 type 属性为 REDIS_LIST ， encoding 属性为 REDIS_ENCODING_LINKEDLIST ，

那么这个对象就是一个 Redis 列表，它的值保存在一个双端链表内，而 ptr 指针就指向这个双端链表；

如果一个 redisObject 的 type 属性为 REDIS_HASH ， encoding 属性为 REDIS_ENCODING_ZIPMAP ，

那么这个对象就是一个 Redis 哈希表，它的值保存在一个 zipmap 里，而 ptr 指针就指向这个 zipmap 。下面这张图片中的REDIS_STRING/REDIS_LIST/REDIS_ZSET/REDIS_HASH/REDIS_SET针对的是redisObject中的type，

后面指向的REDIS_ENCODING_LINKEDLIST等针对的是encoding字段。

Redis的底层数据结构有以下几种：

简单动态字符串sds(Simple Dynamic String)

双端链表(LinkedList)

字典(Map)

跳跃表(SkipList)

下面针对五种数据类型，学习相关的底层数据结构。

2.String

如果一个String类型的value能够保存为整数，则将对应redisObject 对象的encoding修改为REDIS_ENCODING_INT，将对应robj对象的ptr值改为对应的数值。

如果不能转为整数，保持原有encoding为REDIS_ENCODING_RAW。

因此String类型的数据可能使用原始的字符串存储（实际为sds - Simple Dynamic Strings，对应encoding为REDIS_ENCODING_RAW）或者整数存储。

Redis可以直接查看对象的ENCODING值：

redis:6379> set strtest 1
OK
redis:6379> OBJECT ENCODING strtest
"int"
redis:6379> set strtest blog
OK
redis:6379> OBJECT ENCODING strtest
"raw"

3.List

列表的底层实现有2种：

REDIS_ENCODING_ZIPLIST

REDIS_ENCODING_LINKEDLIST

ZIPLIST相比LINKEDLIST可以节省内存，

当创建新的列表时，默认是使用压缩列表作为底层数据结构的。

Redis内部会对相关操作做判断，

当list的elem数小于配置值: hash-max-ziplist-entries 或者elem_value字符串的长度小于 hash-max-ziplist-value, 可以编码成 REDIS_ENCODING_ZIPLIST 类型存储，以节约内存； 但由于在zip list添加和删除元素会涉及到数据移动， 因此当list内容较多时，使用双向链表。

4.Hash

创建新的Hash类型时，默认也使用ziplist存储value，保存数据过多时，使用hast table。

5.Set

集合的底层实现也有两种：

REDIS_ENCODING_INTSET

REDIS_ENCODING_HT(字典)

创建Set类型的key-value时，如果value能够表示为整数，则使用intset类型保存value。

数据量大时，切换为使用hash table保存各个value。

6.Sorted Set

有序集合的底层实现也是2种：

REDIS_ENCODING_ZIPLIST

REDIS_ENCODING_SKIPLIST

为啥 redis 使用跳表(skiplist)而不是使用 red-black？

1、实现简单

2、区间查找，跳表可以做到O(logn) 的时间复杂度定位区间的起点，然后在原始链表中顺序往后遍历就可以了

1.跳表操作时间复杂度和红黑树相同

2.跳表代码实现更易读

3.跳表区间查找效率更高

redis的底层数据结构

在Redis中，只有在使用到不会被修改的字符串字面量时（比如打印日志），Redis才会采用c语言传统的字符串（以空字符结尾的字符数组），而在Redis数据库中，所有的字符串在底层都由SDS来实现的。

底层数据结构分析

SDS是redis中的一种数据结构，叫做简单动态字符串（Simple Dynamic String），并且它是一种二进制安全的，在大多数的情况下redis中的字符串都用SDS来存储。

SDS的数据结构：

struct sdshdr { 
#记录buff数组中已使用字节的数量 
#也是SDS所保存字符串的长度 
int len; 
#记录buff数组中未使用字节的数量 
int free;
 #字节数组，字符串就存储在这个数组里 
char buff[]; }

数据存储示例：

SDS的优点：

1. 时间复杂度为O(1)
2. 杜绝缓冲区溢出
3. 减少修改字符串长度时候所需的内存重分配次数
4. 二进制安全的API操作
5. 兼容部分C字符串函数

关于SDS的详细介绍请大家参阅《redis设计与实现》一文。

redis中的位数组采用的是String字符串数据格式来存储，而字符串对象使用的正是上文说的SDS简单动态字符串数据结构。

动态字符串SDS

SDS是”simple dynamic string”的缩写。

redis中所有场景中出现的字符串，基本都是由SDS来实现的

• 所有非数字的key。例如set msg "hello world" 中的key msg.
• 字符串数据类型的值。例如`` set msg “hello world”中的msg的值”hello wolrd”
• 非字符串数据类型中的“字符串值”。例如RPUSH fruits "apple" "banana" "cherry"中的”apple” “banana” “cherry”

SDS长这样：

free:还剩多少空间

len:字符串长度

buf:存放的字符数组

空间预分配

为减少修改字符串带来的内存重分配次数，sds采用了“一次管够”的策略：

• 若修改之后sds长度小于1MB,则多分配现有len长度的空间
• 若修改之后sds长度大于等于1MB，则扩充除了满足修改之后的长度外，额外多1MB空间

惰性空间释放

为避免缩短字符串时候的内存重分配操作，sds在数据减少时，并不立刻释放空间。

int

就是redis中存放的各种数字

包括一下这种，故意加引号“”的

双向链表

长这样：

分两部分，一部分是“统筹部分”：橘黄色，一部分是“具体实施方“：蓝色。

主体”统筹部分“：

• head指向具体双向链表的头
• tail指向具体双向链表的尾
• len双向链表的长度

具体”实施方”：一目了然的双向链表结构，有前驱pre有后继next

由list和listNode两个数据结构构成。

ziplist

压缩列表。

redis的列表键和哈希键的底层实现之一。此数据结构是为了节约内存而开发的。和各种语言的数组类似，它是由连续的内存块组成的，这样一来，由于内存是连续的，就减少了很多内存碎片和指针的内存占用，进而节约了内存。

然后文中的entry的结构是这样的：

元素的遍历

先找到列表尾部元素：

然后再根据ziplist节点元素中的previous_entry_length属性，来逐个遍历:

连锁更新

再次看看entry元素的结构，有一个previous_entry_length字段，他的长度要么都是1个字节，要么都是5个字节：

• 前一节点的长度小于254字节，则previous_entry_length长度为1字节
• 前一节点的长度小于254字节，则previous_entry_length长度为5字节

假设现在存在一组压缩列表，长度都在250字节至253字节之间，突然新增一新节点new，

长度大于等于254字节，会出现：

程序需要不断的对压缩列表进行空间重分配工作，直到结束。

除了增加操作，删除操作也有可能带来“连锁更新”。

请看下图，ziplist中所有entry节点的长度都在250字节至253字节之间，big节点长度大于254字节，small节点小于254字节。

哈希表

哈希表略微有点复杂。哈希表的制作方法一般有两种，一种是：开放寻址法，一种是拉链法。redis的哈希表的制作使用的是拉链法。

整体结构如下图：

也是分为两部分：左边橘黄色部分和右边蓝色部分，同样，也是”统筹“和”实施“的关系。

具体哈希表的实现，都是在蓝色部分实现的。

先来看看蓝色部分：

这也分为左右两边“统筹”和“实施”的两部分。

右边部分很容易理解：就是通常拉链表实现的哈希表的样式；数组就是bucket，一般不同的key首先会定位到不同的bucket，若key重复，就用链表把冲突的key串起来。

新建key的过程：

假如重复了:

rehash

再来看看哈希表总体图中左边橘黄色的“统筹”部分，其中有两个关键的属性：ht和rehashidx。

ht是一个数组，有且只有俩元素ht[0]和ht[1];其中，ht[0]存放的是redis中使用的哈希表，而ht[1]和rehashidx和哈希表的rehash有关。

rehash指的是重新计算键的哈希值和索引值，然后将键值对重排的过程。

加载因子（load factor） = ht[0].used / ht[0].size。

扩容和收缩标准

扩容：

• 没有执行BGSAVE和BGREWRITEAOF指令的情况下，哈希表的加载因子大于等于1。
• 正在执行BGSAVE和BGREWRITEAOF指令的情况下，哈希表的加载因子大于等于5。

收缩:

• 加载因子小于0.1时，程序自动开始对哈希表进行收缩操作。

扩容和收缩的数量

扩容：

• 第一个大于等于ht[0].used * 2的2^n(2的n次方幂)。

收缩：

• 第一个大于等于ht[0].used的2^n(2的n次方幂)。

(以下部分属于细节分析，可以跳过直接看扩容步骤)

对于收缩，我当时陷入了疑虑：收缩标准是加载因子小于0.1的时候，也就是说假如哈希表中有4个元素的话，哈希表的长度只要大于40，就会进行收缩，假如有一个长度大于40，但是存在的元素为4即(ht[0].used为4)的哈希表，进行收缩，那收缩后的值为多少？

我想了一下：按照前文所讲的内容，应该是4。

但是，假如是4，存在和收缩后的长度相等，是不是又该扩容？

翻开源码看看：

收缩具体函数:

int dictResize(dict *d) //缩小字典d
{
int minimal;
//如果dict_can_resize被设置成0，表示不能进行rehash，或正在进行rehash，返回出错标志DICT_ERR
if (!dict_can_resize || dictIsRehashing(d)) return DICT_ERR;
minimal = d->ht[0].used; //获得已经有的节点数量作为最小限度minimal
if (minimal < DICT_HT_INITIAL_SIZE)//但是minimal不能小于最低值DICT_HT_INITIAL_SIZE（4）
minimal = DICT_HT_INITIAL_SIZE;
return dictExpand(d, minimal); //用minimal调整字典d的大小
}



int dictExpand(dict *d, unsigned long size) //根据size调整或创建字典d的哈希表
{
dictht n;
unsigned long realsize = _dictNextPower(size); //获得一个最接近2^n的realsize
if (dictIsRehashing(d) || d->ht[0].used > size) //正在rehash或size不够大返回出错标志
return DICT_ERR;
if (realsize == d->ht[0].size) return DICT_ERR; //如果新的realsize和原本的size一样则返回出错标志
/* Allocate the new hash table and initialize all pointers to NULL */
//初始化新的哈希表的成员
n.size = realsize;
n.sizemask = realsize-1;
n.table = zcalloc(realsize*sizeof(dictEntry*));
n.used = 0;
/* Is this the first initialization? If so it's not really a rehashing
* we just set the first hash table so that it can accept keys. */
if (d->ht[0].table == NULL) { //如果ht[0]哈希表为空，则将新的哈希表n设置为ht[0]
d->ht[0] = n;
return DICT_OK;
}
d->ht[1] = n; //如果ht[0]非空，则需要rehash
d->rehashidx = 0; //设置rehash标志位为0，开始渐进式rehash（incremental rehashing）
return DICT_OK;
}

static unsigned long _dictNextPower(unsigned long size)
{
unsigned long i = DICT_HT_INITIAL_SIZE; //DICT_HT_INITIAL_SIZE 为 4
if (size >= LONG_MAX) return LONG_MAX + 1LU;
while(1) {
if (i >= size)
return i;
i *= 2;
}
}

由代码我们可以看到，假如收缩后长度为4，不仅不会收缩，甚至还会报错。(😝)

我们回过头来再看看设定：题目可能成立吗？

哈希表的扩容都是2倍增长的，最小是4，

4 ===》 8 ====》 16 =====》 32 ======》 64 ====》 128

也就是说：不存在长度为 40多的情况，只能是64。但是如果是64的话，64 X 0.1（收缩界限）= 6.4 ，也就是说在减少到6的时候，哈希表就会收缩，会缩小到多少呢？是8。此时，再继续减少到4，也不会再收缩了。所以，根本不存在一个长度大于40，但是存在的元素为4的哈希表的。 

扩容步骤

收缩步骤

渐进式refresh

在”扩容步骤”和”收缩步骤” 两幅动图中每幅图的第四步骤“将ht[0]中的数据利用哈希函数重新计算，rehash到ht[1]”，并不是一步完成的，而是分成N多步，循序渐进的完成的。

因为hash中有可能存放几千万甚至上亿个key，毕竟Redis中每个hash中可以存2^32 - 1 键值对（40多亿），假如一次性将这些键值rehash的话，可能会导致服务器在一段时间内停止服务，毕竟哈希函数就得计算一阵子呢((#^.^#))。

哈希表的refresh是分多次、渐进式进行的。

渐进式refresh和下图中左边橘黄色的“统筹”部分中的rehashidx密切相关：

• rehashidx 的数值就是现在rehash的元素位置
• rehashidx 等于 -1 的时候说明没有在进行refresh

甚至在进行期间，每次对哈希表的增删改查操作，除了正常执行之外，还会顺带将ht[0]哈希表相关键值对rehash到ht[1]。

以扩容步骤为例：

intset

整数集合是集合键的底层实现方式之一。

跳表

跳表这种数据结构长这样：

redis中把跳表抽象成如下所示：

看这个图，左边“统筹”，右边实现。

统筹部分有以下几点说明：

• header: 跳表表头
• tail:跳表表尾
• level:层数最大的那个节点的层数
• length：跳表的长度

实现部分有以下几点说明：

• 表头：是链表的哨兵节点，不记录主体数据。
• 是个双向链表
• 分值是有顺序的
• o1、o2、o3是节点所保存的成员，是一个指针，可以指向一个SDS值。
• 层级高度最高是32。没每次创建一个新的节点的时候，程序都会随机生成一个介于1和32之间的值作为level数组的大小，这个大小就是“高度”

www.cnblogs.com/binyue/p/53…

10.重载(Overload)和重写(Override)的区别

重写(Override)

对父类的方法重新编写，返回值和行参不改变，子类可以根据需要，定义特定于自己的行为。 也就是说子类能够根据需要实现父类的方法。

代码示例：

class Animal{
   public void move(){
      System.out.println("动物可以移动");
   }
}
 
class Dog extends Animal{
   @override
   public void move(){
      System.out.println("狗可以跑和走");
   }
}

 方法的重写规则:

• 参数列表必须完全与被重写方法的相同。

• 访问权限不能比父类中被重写的方法的访问权限更低。例如：如果父类的一个方法被声明为 public，那么在子类中重写该方法就不能声明为 protected。

• 声明为 final 的方法不能被重写。

• 声明为 static 的方法不能被重写，但是能够被再次声明。

• 子类和父类在同一个包中，那么子类可以重写父类所有方法，除了声明为 private 和 final 的方法。

• 子类和父类不在同一个包中，那么子类只能够重写父类的声明为 public 和 protected 的非 final 方法。

• 构造方法不能被重写。

• 如果不能继承一个方法，则不能重写这个方法。

Super 关键字的使用

当需要在子类中调用父类的被重写方法时，要使用 super 关键字。

重载(Overload)

重载(overloading) 是在一个类里面，方法名字相同，而参数不同。返回类型可以相同也可以不同。

每个重载的方法（或者构造函数）都必须有一个独一无二的参数类型列表。

最常用的地方就是构造器的重载。

重载规则:

• 被重载的方法必须改变参数列表(参数个数或类型不一样)；

  public class Overloading { public int test(){ System.out.println("test1"); return 1; }

  public void test(int a){
      System.out.println("test2");
  }   
  

  }

总结

方法的重写(Overriding)和重载(Overloading)是java多态性的不同表现，重写是父类与子类之间多态性的一种表现，重载可以理解成多态的具体表现形式。

11.动态代理两种方式的区别

jdk是在运行期间创建一个接口的实现类来完成目标对象的代理。具体步骤：

1. 定义一个实现接口InvocationHandler的
2. 通过构造函数，注入被代理类
3. 实现invoke（ Object proxy, Method method, Object[] args）方法
4. 在主函数中获得被代理类的类加载器
5. 使用Proxy.newProxyInstance( )产生一个代理对象
6. 通过代理对象调用各种方法

cglib动态代理实现。针对类实现代理，对是否实现接口无要求。原理是对指定的类生成一个子类，覆盖其中的方法，因为是继承，所以被代理的类或方法最好不要声明为final类型。具体步骤：

• 定义一个实现了MethodInterceptor接口的类

• 实现其intercept（）方法，在其中调用proxy.invokeSuper( )

12.@Resource和@Autowired的区别

@Resource的作用相当于@Autowired，只不过@Autowired按byType自动注入，而@Resource默认按 byName自动注入。@Reference是dubbo的注解，@Resource是spring的

13.java对象的存活以及回收方式

JVM的内存结构

根据 JVM 规范，JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。

**1. Java虚拟机栈：**线程私有；每个方法在执行的时候会创建一个栈帧，存储了局部变量表，操作数栈，动态连接，方法返回地址等；每个方法从调用到执行完毕，对应一个栈帧在虚拟机栈中的入栈和出栈。

**2. 堆：**线程共享；被所有线程共享的一块内存区域，在虚拟机启动时创建，用于存放对象实例。

**3. 方法区：**线程共享；被所有线程共享的一块内存区域；用于存储已被虚拟机加载的类信息，常量，静态变量等。

**4. 程序计数器：**线程私有；是当前线程所执行的字节码的行号指示器，每条线程都要有一个独立的程序计数器，这类内存也称为“线程私有”的内存。

**5. 本地方法栈：**线程私有；主要为虚拟机使用到的Native方法服务。

成员变量存储在堆内存的对象中，所以也叫对象的特有数据。 静态变量数据存储在方法区（共享数据区）的静态区，所以也叫对象的共享数据。 static 关键字，是一个修饰符，用于修饰成员(成员变量和成员函数)。

1.0判断java对象死活的算法

引用计数算法

我们在很多场景中会听到java对象判断存活的方式是计算该对象的引用计数器是否为0，如果为0就说明没有其他变量引用该对象了，这个对象就可以被垃圾收集器回收了。

可达性分析算法

java中判断对象是否可以回收是通过可达性分析算法来实现的。如下图:

在上图中object5,object6及object7这三个对象虽然有相互之间的引用，但是通过GC Roots对象并不能引用到这三个对象，所以这三个对象是满足回收条件的，而对象1到4通过GC Roots可达，所以这几个对象任然存活。

JVM 判断对象是否回收?
答案就是GC roots。也就是从根对象出发，没有任何一个对象引用到它，那么就判断这个对象是不可达的。
通常被骂“断子绝孙”的人，就是要被回收的root

在java中，可作为GC Roots的对象有：

1.虚拟机栈（栈帧中的本地变量表）中引用的对象；

2.方法区中的类静态属性引用的对象；

3.方法区中常量引用的对象；

4.本地方法栈中JNI（即一般说的Native方法）中引用的对象

所以不要让他们过度繁殖。

4.方法区的回收

方法区的回收分为废弃常量的回收和无用类的卸载。

• 废弃常量的回收：回收废弃常量与上面所说的堆中对象的回收差不多，没有任何引用的时候回收。

• 无用类的卸载：类的卸载需要满足三个条件：

1. 该类的所有对象都被回收。
2. 加载该类的ClassLoader已经被回收。
3. 该类对应的java.lang.Class没有在任何地方被引用，无法在任何地方通过反射访问该类。 但是满足这三个条件只是说可以被回收，但是不代表一定被回收，具体是否被回收还要由虚拟机里的一些参数来具体确定。

2.0垃圾回收的算法

2.1 标记-清除算法

正如这个算法的名称一般，其总共有两个阶段——"标记"和"清除"：首先其会对所有的死亡对象进行标记，最后再一起将这些对象回收。

这个算法是基础的算法，后续的算法都是对其缺点的一些改进。此算法有两个不足的地方，其一从上图也可以看得出来，垃圾回收后的内存空间不连续，造成许多的内存碎片。其二就是其效率问题，标记和清除的效率并不是太高，所以后续出现的算法都对两个缺点的调整和改进。

2.2 复制算法上图也可以看得出，对此算法最重要的是内存空间的切分，如果切分不当可能会浪费大量的空间。当然使用得当也有十分值得的优点：一定范围内的高效率和没有内存碎片。

上图也可以看得出，对此算法最重要的是内存空间的切分，如果切分不当可能会浪费大量的空间。当然使用得当也有十分值得的优点：一定范围内的高效率和没有内存碎片。

缺点：

      1、适用于存活对象相较死亡对象少的情况，例如新生代，如果存活的对象较多的话可能得到相反的效果。所以才说是一定范围的高效率。

     2、需要划分内存空间。如果本身的内存空间比较小还去划分的话那可能会导致频繁的GC，停顿时间增多，影响用户体验。

　另：此算法一般用在新生代做垃圾回收算法，并且将新生代分成三个部分——两个Survivor和一个Eden区，其比例默认为1：1：8（可以通过虚拟机参数改变）。

当我们生成一个对象（通过关键字new或者反射）的时候，对象首先会分配在Eden区，等到Eden区放不下的时候则触发一次MinorGC，将Eden和其中一个Survivor中的存活对象一起移到另一个Survivor中，然后清空。顺带一提，有存活对象的Survivor总是称作From区，空白的Suvivor总是称作To区，一般新生代存活对象占5%左右。

2.3 标记-整理法

复制算法是一个非常优秀的算法，但其只在存活对象想多较少的情况下表现良好，而对于其他例如年老代中这些存活对象较多的区域则可能是一种糟糕的选择。所以，需要一个更加合适的算法——标记-整理法。这个算法原理和步骤基本跟标记-清除一样，但是多出一个整理的步骤，也就是说整个过程为标记-清除-整理，结束之后不会产生内存碎片。 

严格来说这不能算是一种算法，应该是一种理念。其把整个内存空间分为两个区域——新生代和年老代(1.8之前还有一个永久代，也就是方法区，但是在1.8之后已经删除)。并且虚拟机对对象定义了年龄的概念，表示该对象熬过了多少次GC，以此来作为对象放在新生代还是年老代的标准之一，默认新生代的对象15岁之后就可以进入年老代了。对于两个区域采用的回收算法也是不同的，新生代一般采用复制算法，年老代一般采用标记-整理法，当然具体还是得看使用的垃圾回收器，如果年老代使用的是CMS的话那么就是标记-清除了。 

14.数据库事务隔离级别

事务（transaction） 定义：事务就是一个对数据库操作的序列，是一个不可分割的工作单位，要不这个序列里面的操作全部执行，要不全部不执行。

一、数据库事务隔离级别

Read uncommitted 读未提交

当隔离级别设置为Read uncommitted 时，就可能出现脏读

Read committed 读提交

当隔离级别设置为Read committed 时，避免了脏读，但是可能会造成不可重复读。

Repeatable read 重复读

当隔离级别设置为Repeatable read 时，可以避免不可重复读。虽然Repeatable read避免了不可重复读，但还有可能出现幻读 。

注：Mysql的默认隔离级别就是Repeatable read。

Serializable 序列化

Serializable 是最高的事务隔离级别，同时代价也花费最高，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻像读。

****二、脏读、幻读、不可重复读

1.脏读：

脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。

2.不可重复读：

是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。（即不能读到相同的数据内容）

3.幻读:

是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象
发生了幻觉一样。

16.乐观锁和悲观锁的区别

乐观锁与悲观锁不是指具体的什么类型的锁，而是指看待并发同步的角度。

• 悲观锁认为对于同一个数据的并发操作，一定是会发生修改的，哪怕没有修改，也会认为修改。因此对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。

• 乐观锁则认为对于同一个数据的并发操作，是不会发生修改的。在更新数据的时候，会采用尝试更新，不断重新的方式更新数据。乐观的认为，不加锁的并发操作是没有事情的。

从上面的描述我们可以看出，悲观锁适合写操作非常多的场景，乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升。

悲观锁在Java中的使用，就是利用各种锁。

悲观锁

悲观锁，其实就是正常的锁。就是以下几个步骤。

步骤

1.获取锁

2.修改数据

3.释放锁

应用场景

比如，更新数据库里的某行数据。

如何加锁？

查询sql后面加for update。

上面的场景中，商品信息从查询出来到修改，中间有一个处理订单的过程，使用悲观锁的原理就是，当我们在查询出goods信息后就把当前的数据锁定，直到我们修改完毕后再解锁。在这个过程中，因为goods被锁定了，就不会出现有第三者来对其进行修改了。

注：要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。

可以使用命令设置MySQL为非autocommit模式：

set autocommit=0;

然后就可以执行正常业务了。具体如下：

开始事务

begin;/begin work;/start transaction; (三者选一就可以)

查询出商品信息

select status from goods where id=1 for update;

根据商品信息生成订单

insert into t_orders (goods_id) values (1);

修改商品status为2

update goods set status=2;

提交事务

commit;/commit work;(任选一)

与普通查询不一样的是，使用了select…for update的方式，这样就通过数据库实现了悲观锁。此时在goods表中，id为1的 那条数据就被锁定了，其它的事务必须等本次事务提交之后才能执行。这样就可以保证当前的数据不会被其它事务修改。

注：在事务中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一笔数据时会等待其它事务结束后才执行，一般SELECT ... 则不受此影响。拿上面的实例来说，当执行select status from goods where id=1 for update后，另外的事务中如果再次执行select status from t_goods where id=1 for update，则会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果在第二个事务中执行select status from t_goods where id=1;则能正常查询出数据，不会受第一个事务的影响。

乐观锁

乐观锁在Java中的使用，是无锁编程，常常采用的是CAS算法，典型的例子就是原子类，通过CAS自旋实现原子操作的更新。

乐观锁顾名思义就是在操作时很乐观，认为操作不会产生并发问题(不会有其他线程对数据进行修改)，因此不会上锁。但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS(compare and swap)算法实现。 简单理解：这里的数据，别想太多，你尽管用，出问题了算我怂，即操作失败后事务回滚、提示。

1.版本号机制

1.1.1 实现套路：

• 取出记录时，获取当前version

• 更新时，带上这个version

• 执行更新时， set version = newVersion where version = oldVersion

• 如果version不对，就更新失败

核心SQL：

update table set name = 'Aron', version = version + 1 where id = #{id} and version = #{version};

3.mysql sql语句的优化

1、应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

2、对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

3、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num=0

4、尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or num=20

可以这样查询：

select id from t where num=10
 
union all
 
select id from t where num=20

5、尽量避免在字段开头模糊查询，会导致数据库引擎放弃索引进行全表扫描

如下：

SELECT * FROM t WHERE username LIKE '%陈%' 

优化方式：尽量在字段后面使用模糊查询。

如下：

SELECT * FROM t WHERE username LIKE '陈%' 

6、in 和 not in 也要慎用，否则会导致全表扫描，如：

select id from t where num in(1,2,3)

对于连续的数值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

7、如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

select id from t where num=@num

可以改为强制查询使用索引：

select id from t with(index(索引名)) where num=@num

8、应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where num/2=100

应改为:

select id from t where num=100*2

9、应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where substring(name,1,3)=’abc’–name以abc开头的id
 
select id from t where datediff(day,createdate,’2005-11-30′)=0–’2005-11-30′生成的id
 

应改为:

select id from t where name like ‘abc%’
 
select id from t where createdate>=’2005-11-30′ and createdate<’2005-12-1′
 

10、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

11、很多时候用 exists 代替 in 是一个好的选择：

select num from a where num in(select num from b)

用下面的语句替换：

select num from a where exists(select 1 from b where num=a.num)

12、任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。

13、order by 条件要与 where 中条件一致，否则 order by 不会利用索引进行排序

如下：

-- 不走age索引 
SELECT * FROM t order by age; 
 
-- 走age索引 
SELECT * FROM t where age > 0 order by age; 

MySQL having的用法

having字句可以让我们筛选成组后的各种数据，where字句在聚合前先筛选记录，也就是说作用在group by和having字句前。而 having子句在聚合后对组记录进行筛选。我的理解就是真实表中没有此数据，这些数据是通过一些函数生存。

MySQL之Where和Having的区别

Where是一个约束声明，在查询数据库的结果返回之前对数据库中的查询条件进行约束，即在结果返回之前起作用，且where后面不能使用聚合函数

Having是一个过滤声明，所谓过滤是在查询数据库的结果返回之后进行过滤，即在结果返回之后起作用，并且having后面可以使用聚合函数。

所谓聚合函数，是对一组值进行计算并且返回单一值的函数：sum—求和，count—计数，max—最大值，avg—平均值等。

从使用的角度：

where后面之所以不能使用聚合函数是因为where的执行顺序在聚合函数之前，如下面这个sql语句：

  select  sum(score) from student  group by student.sex where sum(student.age)>100;

having既然是对查出来的结果进行过滤，那么就不能对没有查出来的值使用having，如下面这个sql语句：

select  student.id,student.name from student having student.score >90;