暂无。
有关线程部分的知识整理请看我下面这篇博客：
他的主要特点为：
线程复用；不需要频繁的创建和销毁线程；控制线程数量：处理过程中将任务放入队列，然后在线程创建后● ArrayBlockingQueue 由数组支持的有界队列
● LinkedBlockingQueue 由链接节点支持的可选有界队列
○ newFixedThreadPool
○ newSingleThreadPool
● DelayQueue 由优先级堆支持的、基于时间的调度无界队列（PriorityBlockingQueue ）
○ ScheduleThreadPoolExecutor
他们的顶级接口都是：BlockingQueue。
和线程一样，线程池也存在生命周期。
底层源码，都是对线程池的状态进行判断，所以，此处把线程池的状态必须记住。
RUNNING = -1 << COUNT_BITS; //高3位为111
SHUTDOWN = 0 << COUNT_BITS; //高3位为000
STOP = 1 << COUNT_BITS; //高3位为001
TIDYING = 2 << COUNT_BITS; //高3位为010
TERMINATED = 3 << COUNT_BITS; //高3位为011
(1) 状态说明：线程池处在RUNNING状态时，能够接收新任务，以及对已添加的任务进行处理。
(2) 状态切换：线程池的初始化状态是RUNNING。换句话说，线程池被一旦被创建，就处于RUNNING状态，并且线程池中的任务数为0！
(1) 状态说明：线程池处在SHUTDOWN状态时，不接收新任务，但能处理已添加的任务。
(2) 状态切换：调用线程池的shutdown()接口时，线程池由RUNNING -> SHUTDOWN。
(1) 状态说明：线程池处在STOP状态时，不接收新任务，不处理已添加的任务，并且会中断正在处理的任务。
(2) 状态切换：调用线程池的shutdownNow()接口时，线程池由(RUNNING or SHUTDOWN ) -> STOP。
(1) 状态说明：当所有的任务已终止，ctl记录的“任务数量”为0，线程池会变为TIDYING状态。当线程池变为TIDYING状态时，会执行钩子函数terminated()。terminated()在ThreadPoolExecutor类中是空的，若用户想在线程池变为TIDYING时，进行相应的处理；可以通过重载terminated()函数来实现。
(2) 状态切换：当线程池在SHUTDOWN状态下，阻塞队列为空并且线程池中执行的任务也为空时，就会由 SHUTDOWN -> TIDYING。 当线程池在STOP状态下，线程池中执行的任务为空时，就会由STOP -> TIDYING。
(1) 状态说明：线程池彻底终止，就变成TERMINATED状态。
(2) 状态切换：线程池处在TIDYING状态时，执行完terminated()之后，就会由 TIDYING -> TERMINATED。
进入TERMINATED的条件如下：
● 线程池不是RUNNING状态；
● 线程池状态不是TIDYING状态或TERMINATED状态；
● 如果线程池状态是SHUTDOWN并且workerQueue为空；
● workerCount为0；
● 设置TIDYING状态成功。
在线程池的使用中，我们一般用ThreadPoolExecutor来创建线程池，创建好线程池后会将任务提交给线程池来执行。在提交任务的时候，JDK为我们提供了两种不同的提交方式，分别是submit()和excute()
1.接收参数不同
execute只能接受Runnable类型的任务；
submit不管是Runnable还是Callable类型的任务都可以接受，但是Runnable返回值均为void，所以使用Future的get()获得的还是null。
2.对异常的处理不同
excute方法会抛出异常。
sumbit方法不会抛出异常。除非你调用Future.get()
3.对返回值的处理不同
execute方法不关心返回值。
submit方法有返回值，Future.
提交任务和执行任务：
线程池中，提交任务（ submit() 和 execute()）和执行任务的顺序是不一样的;
提交任务：核心线程 => 队列 => 非核心线程
执行任务：核心线程 => 非核心线程 => 队列
创建线程若线程数等于最大线程数，抛出异常，拒绝任务如下：
1、丢弃任务并抛出RejectedExecutionException异常（默认）
● new ThreadPoolExecutor.AbortPolicy();
2、丢弃任务但是不抛出异常 - Discard：
● new ThreadPoolExecutor.DiscardPolicy();
3、丢弃队列最前面的任务，最新任务入列
● new ThreadPoolExecutor.DiscardOldestPolicy();
4、由调用线程处理该任务
● new ThreadPoolExecutor.CallerRunsPolicy();
Java面试题之Executor 和Executors 区别
Executor 接口对象能执行我们的线程任务；
Executors 工具类的不同方法按照我们的需求创建了不同的线程池，来满足业务的需求。
ExecutorService 接口继承了Executor接口并进行了扩展，提供了更多的方法，我们能够获得任务执行的状态并且可以获取任务的返回值。
A：其实这道题是在问你用线程池和不用线程池的区别。
对于Executor框架，他代表一系列线程池，如果有100个任务我们可以只创建几个线程去完成，节省cpu资源；
而对于Thread类，他就需要创建100个线程去执行这100个任务，消耗cpu资源。
此处，通过代码的方式，分析下面三个线程池在执行100个任务的时候，所耗时长是多少？并且分析为什么耗时不一样？
public class ThreadPoolDemo {
public static void main(String[] args) {
ExecutorService executorService1 = Executors.newFixedThreadPool(10); //慢
ExecutorService executorService2 = Executors.newCachedThreadPool(); //快
ExecutorService executorService3 = Executors.newSingleThreadExecutor(); //最慢
//自定义的线程池--执行第（maximumpoolsize+capacity）个任务的时候报错（拒绝策略）
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor
(10,20,0L, TimeUnit.MILLISECONDS,new ArrayBlockingQueue<>(20));
for(int i = 0; i<100; i++){
//executorService2.execute(new MyTask(i));
threadPoolExecutor.execute(new MyTask(i));
}
}
}
class MyTask implements Runnable{
int i = 0;
public MyTask(int i){
this.i = i;
}
@Override
public void run() {
System.out.println(Thread.currentThread().getName()+"--"+i);
try {
Thread.sleep(1000L);
}catch (Exception e){
}
Q1：为什么newCachedThreadPool的方式更快？
那么我们就需要从底层源码的角度去分析。
A1：newCachedThreadPool
newCachedThreadPool的核心线程数是0，但是最大线程数是Integer的最大值。并且，没有用到队列存储任务。
以我们上面代码为例，输出结果并没有体现出newCachedThreadPool这个线程池的线程复用的特点，因为我们故意让线程休眠了1s：如果有100个任务过来，他就会创建100个非核心线程；1000个任务过来，创建1000个非核心线程。。。来多少任务给你创建多少线程。
如果我们把休眠1s去掉，那么就体现了newCachedThreadPool线程复用的特点：100个任务，并不会给你创建100个线程，而是可能只有50个或者40个线程。因为同一个线程可能会执行多个任务。
那为什么加了1s休眠结果却是100个任务就会有100个线程被创建呢？
-答案也很简单，一个线程处理一个任务的速度很快的，可能1纳秒就处理完了，而你让他休眠了整整一秒。等他醒过来，任务早己被其他线程处理了。
面试回答的时候需要注意的点：
把你的场景给面试官描述清楚，比如休眠1s。不同的场景得到的结论是有差异的。 我们上面代码的结论就可以从输出结果中找到。
线程复用的确是newCachedThreadPool的特点，理论上来说线程复用就是一个线程处理了多个任务，但我上面休眠1s的场景却始终重现不了一个线程处理多个任务的输出结果，输出结果都是一个线程处理一个任务。
引发的思考：
并发编程中，理论上出现的问题在我们实际操作中很难让场景重现。所以我们就感觉他很难，包括在看一些书的时候，感觉都好抽象。 我们可以推测出某个场景，但是往往我们无法用代码把这个场景重现出来，以上面休眠1s为例。 休眠1s就是在假设这个任务执行的是sql查询操作，耗时为1s。这个场景还是好模拟的，不过还是有很多场景需要专门的测试人员使用工具去模拟。
A2: newFixedThreadPool
newFixedThreadPool的核心线程数是是10，最大线程数也是10，因此他的线程池里面只有10个线程。
如果有100个任务过来，10个线程先来处理10个任务，剩下90个任务放到(无界)任务队列里面；
10个任务执行完后，再从任务队列里面再拿10个任务，那么无界任务队列里面还剩下80个任务；
…
特点就是，10个任务10个任务的执行。你可以测试上面的代码块，每执行10个任务，都会有停顿。
A3：newSingleThreadExecutor
和newFixedThreadPool很像，唯一的区别就是只有1个核心线程，所以慢。
Q2：为什么阿里巴巴开发手册不推荐以上三种方式创建线程？
A：都有可能触发OOM内存溢出。
newFixedThreadPool和newSingleThreadExecutor都有无界阻塞队列，理论上说任务挤压是可以无限存放的，那么肯定溢出。
newCachedThreadPool就是任务多的时候虽然不会往任务队列放（队列里面只有一个任务的位置），但是他会给你一直创建线程，非常消耗cup资源最终内存溢出。
当然，我们前面说了，场景很重要。因为阿里并发量很大，所以不采用以上三种方式，但是普通小公司没有那么大的并发量完全是可以使用的。
那我们应该使用哪种方式创建线程呢？
-阿里推荐我们使用自定义线程池。
A1：通过分析上面三个方式的源码知道，其实是和线程池参数有关：
看业务：
有自己实现过线程池吗？你是怎么实现的，里面的参数你是怎么设置的。（阿里面试题）
https://blog.csdn.net/sakuragio/article/details/100666596
我们可以把任务分为计算（CPU）密集型和IO密集型。
计算密集型（CPU）任务的特点是要进行大量的计算，消耗CPU资源，比如计算圆周率、从1加到一亿等等，全靠CPU的运算能力。
CPU密集型也叫计算密集型，指的是系统的硬盘、内存性能相对CPU要好很多，此时，系统运作大部分的状况是CPU Loading 100%，CPU要读/写I/O(硬盘/内存)，I/O在很短的时间就可以完成，而CPU还有许多运算要处理，CPU Loading很高。
假如在单核CPU情况下，线程池有6个线程，但是由于是单核CPU，所以同一时间只能运行一个线程，考虑到线程之间还有上下文切换的时间消耗，还不如单个线程执行高效。
所以！！！单核CPU处理CPU密集型程序，就不要使用多线程了。
假如是6个核心的CPU，理论上运行速度可以提升6倍。每个线程都有 CPU 来运行，并不会发生等待 CPU 时间片的情况，也没有线程切换的开销。
所以！！！多核CPU处理CPU密集型程序才合适，而且中间可能没有线程的上下文切换（一个核心处理一个线程）。
简单的说，就是需要CPU疯狂的计算。
1、定时类线程池，或者叫做延迟类线程池。因为这个类带来两个功能：1.定时 2.延迟。
2、在延迟类线程池中，是没有【非核心线程数】的，只有【核心线程数】。
三个重要方法 :
它接收SchduledFutureTask类型的任务，是线程池调度任务的最小单位，有三种提交任务的方式：
- schedule
- scheduledAtFixedRate
- scheduledWithFixedDelay
它采用DelayQueue存储等待的任务
根据time的先后时间排序，若time相同则根据sequenceNumber排序；
下面的案例演示的是：延迟执行。
真实项目中，具体延迟多长时间是需要预估的。怎么预估？任务执行前后输出两个时间，然后相减。
场景：当springboot项目启动的时候，故意延迟5s，让一些监听器、拦截器等初始化完毕（bean注入到容器）。
应用：在实际项目开发的时候，根据自己的业务场景设置延迟几秒执行。
场景：主线程扔给延迟类线程池执行一个任务，且主线程继续执行自己的逻辑（异步）；当延迟类线程池执行任务完毕会返回一个值给主线程，主线程拿到这个值再去做其他的业务逻辑。
异步的阻塞处理：主线程提交了任务给延迟类线程池之后，不会等延迟类线程池执行完任务再执行自己的代码，主线程而是直接执行自己下面的代码（业务逻辑）； 当延迟类线程池执行完任务之后，会返回一个值，这个值会被主线程调用的get捕获到。
场景描述：项目启动成功1s后，执行任务；然后每次间隔2s执行任务。
ScheduledThreadPoolExecutor scheduledThreadPoolExecutor = new ScheduledThreadPoolExecutor(1);
ScheduledThreadPoolExecutor scheduledThreadPoolExecutor = new ScheduledThreadPoolExecutor(1);
scheduledThreadPoolExecutor.scheduleAtFixedRate(() -> {
log.info("send heart beat");
long starttime = System.currentTimeMillis(), nowtime = starttime;
while ((nowtime - starttime) < 5000) {
nowtime = System.currentTimeMillis();
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
log.info("task over....");
throw new RuntimeException("unexpected error , stop working");
}, 1000, 2000, TimeUnit.MILLISECONDS);
第14行抛出一个异常，会造成什么结果呢？
— 上一节我们讲过，如果线程池在执行任务的时候发生异常，那么正在执行的这个任务就会被丢弃掉，执行该任务的线程死亡，但是线程池依然存在，当新任务来的时候线程池会创建**非核心线程**。虽然线程池存在，但是没有任务了（因为只调用一次scheduleAtFixedRate，只有一个任务，而且这个任务发生异常被丢弃了），所以程序一直阻塞着等待任务。因此在实际开发中，我们必须在执行任务代码进行异常捕获（进行捕获后任务不会被抛弃）。
输出结果：
程序不会停止，一直处于运行状态，但是没有任务给他执行（由于异常没有被捕获，造成任务丢失，所以没有任务了） 。
因此在实际开发中，必须在执行任务的时候进行异常捕获（try，catch）
调用两次scheduleAtFixedRate：
ScheduledThreadPoolExecutor scheduledThreadPoolExecutor = new ScheduledThreadPoolExecutor(1);
// 提交第一个任务。
// 线程a，会发生异常，且这个异常没有被捕获。
// 那么，在发生异常的时候该【任务被丢弃】，该线程池执行该任务的【线程死掉】。
scheduledThreadPoolExecutor.scheduleAtFixedRate(() -> {
log.info("a线程：send heart beat");
long starttime = System.currentTimeMillis(), nowtime = starttime;
while ((nowtime - starttime) < 5000) {
nowtime = System.currentTimeMillis();
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
log.info("a线程：task over....");
throw new RuntimeException("unexpected error , stop working");
}, 1000, 2000, TimeUnit.MILLISECONDS);
// 提交第二个任务。
// 由于我们进行了异常捕获，该【线程不会死掉】且该【任务不会被丢弃】。
// 注意：此时的线程是非核心线程，唯一的一个核心线程在上一次执行异常任务未捕获异常中死掉了。
scheduledThreadPoolExecutor.scheduleAtFixedRate(() -> {
try {
log.info("b线程：send heart beat");
long starttime = System.currentTimeMillis(), nowtime = starttime;
while ((nowtime - starttime) < 5000) {
nowtime = System.currentTimeMillis();
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
log.info("b线程：task over....");
throw new RuntimeException("unexpected error , stop working");
}catch (Exception e){
e.getMessage();
}
}, 1000, 2000, TimeUnit.MILLISECONDS);
执行结果：
D:\A-MyInstall\Java\JDK_64_1.8\bin\java.exe "-javaagent:D:\A-MyInstall\IntelliJ IDEA 2019.2.4\lib\idea_rt.jar=58193:D:\A-MyInstall\IntelliJ IDEA 2019.2.4\bin" -Dfile.encoding=UTF-8 -classpath D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\charsets.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\deploy.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\access-bridge-64.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\cldrdata.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\dnsns.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\jaccess.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\jfxrt.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\localedata.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\nashorn.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\sunec.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\sunjce_provider.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\sunmscapi.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\sunpkcs11.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\ext\zipfs.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\javaws.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\jce.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\jfr.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\jfxswt.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\jsse.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\management-agent.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\plugin.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\resources.jar;D:\A-MyInstall\Java\JDK_64_1.8\jre\lib\rt.jar;D:\A-MyFile\学习文档\图灵学院\VIP第四期\二：并发编程专题\14.编发编程之Future&ForkJoin框架原理分析\tuling-juc-final\juc-threadpool\target\classes;D:\repository\junit\junit\4.12\junit-4.12.jar;D:\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar;D:\repository\co\paralleluniverse\quasar-core\0.7.6\quasar-core-0.7.6.jar;D:\repository\org\hdrhistogram\HdrHistogram\2.1.9\HdrHistogram-2.1.9.jar;D:\repository\io\dropwizard\metrics\metrics-core\4.0.5\metrics-core-4.0.5.jar;D:\repository\org\latencyutils\LatencyUtils\2.0.3\LatencyUtils-2.0.3.jar;D:\repository\de\javakaffee\kryo-serializers\0.38\kryo-serializers-0.38.jar;D:\repository\com\google\protobuf\protobuf-java\2.6.1\protobuf-java-2.6.1.jar;D:\repository\com\google\guava\guava\19.0\guava-19.0.jar;D:\repository\com\esotericsoftware\kryo\4.0.0\kryo-4.0.0.jar;D:\repository\com\esotericsoftware\reflectasm\1.11.3\reflectasm-1.11.3.jar;D:\repository\com\esotericsoftware\minlog\1.3.0\minlog-1.3.0.jar;D:\repository\org\objenesis\objenesis\2.2\objenesis-2.2.jar;D:\repository\org\springframework\boot\spring-boot-starter-web\2.1.7.RELEASE\spring-boot-starter-web-2.1.7.RELEASE.jar;D:\repository\org\springframework\boot\spring-boot-starter\2.1.7.RELEASE\spring-boot-starter-2.1.7.RELEASE.jar;D:\repository\org\springframework\boot\spring-boot\2.1.7.RELEASE\spring-boot-2.1.7.RELEASE.jar;D:\repository\org\springframework\boot\spring-boot-autoconfigure\2.1.7.RELEASE\spring-boot-autoconfigure-2.1.7.RELEASE.jar;D:\repository\org\springframework\boot\spring-boot-starter-logging\2.1.7.RELEASE\spring-boot-starter-logging-2.1.7.RELEASE.jar;D:\repository\ch\qos\logback\logback-classic\1.2.3\logback-classic-1.2.3.jar;D:\repository\ch\qos\logback\logback-core\1.2.3\logback-core-1.2.3.jar;D:\repository\org\slf4j\slf4j-api\1.7.26\slf4j-api-1.7.26.jar;D:\repository\org\apache\logging\log4j\log4j-to-slf4j\2.11.2\log4j-to-slf4j-2.11.2.jar;D:\repository\org\apache\logging\log4j\log4j-api\2.11.2\log4j-api-2.11.2.jar;D:\repository\org\slf4j\jul-to-slf4j\1.7.26\jul-to-slf4j-1.7.26.jar;D:\repository\javax\annotation\javax.annotation-api\1.3.2\javax.annotation-api-1.3.2.jar;D:\repository\org\springframework\spring-core\5.1.9.RELEASE\spring-core-5.1.9.RELEASE.jar;D:\repository\org\springframework\spring-jcl\5.1.9.RELEASE\spring-jcl-5.1.9.RELEASE.jar;D:\repository\org\yaml\snakeyaml\1.23\snakeyaml-1.23.jar;D:\repository\org\springframework\boot\spring-boot-starter-json\2.1.7.RELEASE\spring-boot-starter-json-2.1.7.RELEASE.jar;D:\repository\com\fasterxml\jackson\core\jackson-databind\2.9.9\jackson-databind-2.9.9.jar;D:\repository\com\fasterxml\jackson\core\jackson-annotations\2.9.0\jackson-annotations-2.9.0.jar;D:\repository\com\fasterxml\jackson\core\jackson-core\2.9.9\jackson-core-2.9.9.jar;D:\repository\com\fasterxml\jackson\datatype\jackson-datatype-jdk8\2.9.9\jackson-datatype-jdk8-2.9.9.jar;D:\repository\com\fasterxml\jackson\datatype\jackson-datatype-jsr310\2.9.9\jackson-datatype-jsr310-2.9.9.jar;D:\repository\com\fasterxml\jackson\module\jackson-module-parameter-names\2.9.9\jackson-module-parameter-names-2.9.9.jar;D:\repository\org\springframework\boot\spring-boot-starter-tomcat\2.1.7.RELEASE\spring-boot-starter-tomcat-2.1.7.RELEASE.jar;D:\repository\org\apache\tomcat\embed\tomcat-embed-core\9.0.22\tomcat-embed-core-9.0.22.jar;D:\repository\org\apache\tomcat\embed\tomcat-embed-el\9.0.22\tomcat-embed-el-9.0.22.jar;D:\repository\org\apache\tomcat\embed\tomcat-embed-websocket\9.0.22\tomcat-embed-websocket-9.0.22.jar;D:\repository\org\hibernate\validator\hibernate-validator\6.0.17.Final\hibernate-validator-6.0.17.Final.jar;D:\repository\javax\validation\validation-api\2.0.1.Final\validation-api-2.0.1.Final.jar;D:\repository\org\jboss\logging\jboss-logging\3.3.2.Final\jboss-logging-3.3.2.Final.jar;D:\repository\com\fasterxml\classmate\1.4.0\classmate-1.4.0.jar;D:\repository\org\springframework\spring-web\5.1.9.RELEASE\spring-web-5.1.9.RELEASE.jar;D:\repository\org\springframework\spring-beans\5.1.9.RELEASE\spring-beans-5.1.9.RELEASE.jar;D:\repository\org\springframework\spring-webmvc\5.1.9.RELEASE\spring-webmvc-5.1.9.RELEASE.jar;D:\repository\org\springframework\spring-aop\5.1.9.RELEASE\spring-aop-5.1.9.RELEASE.jar;D:\repository\org\springframework\spring-context\5.1.9.RELEASE\spring-context-5.1.9.RELEASE.jar;D:\repository\org\springframework\spring-expression\5.1.9.RELEASE\spring-expression-5.1.9.RELEASE.jar;D:\repository\org\projectlombok\lombok\1.18.8\lombok-1.18.8.jar com.yg.edu.schedule.ScheduleThreadPoolRunner
20:46:41.249 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - a线程：send heart beat
20:46:46.403 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - a线程：task over....
20:46:46.403 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：send heart beat
20:46:51.527 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：task over....
20:46:51.527 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：send heart beat
20:46:56.656 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：task over....
20:46:56.656 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：send heart beat
20:47:01.782 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：task over....
20:47:01.782 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：send heart beat
20:47:06.906 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：task over....
20:47:06.906 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：send heart beat
20:47:12.032 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：task over....
20:47:12.032 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：send heart beat
20:47:17.156 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：task over....
20:47:17.156 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：send heart beat
20:47:22.280 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：task over....
20:47:22.280 [pool-1-thread-1] INFO com.yg.edu.schedule.ScheduleThreadPoolRunner - b线程：send heart beat
try，catch捕获之后的程序 – - 任务没有被丢弃，程序一直运行着该任务:
ScheduledThreadPoolExecutor scheduledThreadPoolExecutor = new ScheduledThreadPoolExecutor(1);
上面场景的任务只是简单的输出一行代码，真实场景中这个任务会进行非常复杂的操作，耗时10s，可是任务每2s就被执行，这会产生什么结果呢（注意：我只创建了一个核心线程执行任务，从始至终只有一个线程）？
--------会造成任务堆积。
下面，我们代码模拟一下上面的场景：
@Slf4j
public class ScheduleThreadPoolRunner {
public static void main(String[] args) {
// 创建延迟类线程池，核心线程数是1.
ScheduledThreadPoolExecutor scheduledThreadPoolExecutor = new ScheduledThreadPoolExecutor(1);
// 发心跳，service1->service2,每次过5s，发送一个心跳，证明s2可用
// 注意：调用一次scheduleAtFixedRate是执行一个任务，调用两次是提交两个任务。
scheduledThreadPoolExecutor.scheduleAtFixedRate(() -> {
log.info("send heart beat");
long starttime = System.currentTimeMillis(), nowtime = starttime;
// 如果当前时间减去开始时间小于5s，则一直循环。
while ((nowtime - starttime) < 5000) {
nowtime = System.currentTimeMillis();
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
log.info("task over....");
throw new RuntimeException("unexpected error , stop working");
}, 1000, 2000, TimeUnit.MILLISECONDS);
结果：
代码不会报错。 虽然定义任务每2s执行一次，实际任务耗时5s；从结果来看，当任务执行结束，会立马再次执行任务。
造成的问题：我实际规定的是2s执行一次任务，你每次执行任务都耗费5s，随着时间增加，肯定会造成任务的堆积。以上场景等同于：a把家具从楼下搬到楼上耗时5s，b每2s都往楼下放新的家具；10s后，b放了5个家具，a搬上2个家具；那么100s后、1000s后、100000s后，任务不断堆积（往队列里面一直放），肯定就会造成OOM。
注意：调用一次scheduleAtFixedRate提交一次任务，调用两次是提交两次任务。
那，怎么解决任务堆积问题呢？
而且，即使可以创建非核心线程数也不会让你一直创建下去。原因：一直创建最终肯定会造成OOM。
这时候就有人说，创建多点核心线程数不就行了；但是注意：调用一次scheduleAtFixedRate提交一次任务，调用两次scheduleAtFixedRate是提交两次任务，每个任务都会对应一个核心线程数。我们上面的案例是创建一个核心线程，每2s执行一次任务都是这一个线程执行的；即使你创建10个核心线程，你只调用一次scheduleAtFixedRate，那么每2s执行一次任务都只是一个核心线程执行。
ScheduledThreadPoolExecutor给我们提供了另一个API，可以解决以上问题。
—scheduleWithFixedDelay方法。
使用场景：分布式锁-redis，消息中间件（把任务放到消息队列，然后定时去消费任务）。
@Slf4j
public class ScheduleThreadPoolRunner {
public static void main(String[] args) {
ScheduledThreadPoolExecutor scheduledThreadPoolExecutor = new ScheduledThreadPoolExecutor(1);
//发心跳，service1->service2,每次过5s，发送一个心跳，证明s2可用
scheduledThreadPoolExecutor.scheduleWithFixedDelay(() -> {
log.info("send heart beat");
long starttime = System.currentTimeMillis(), nowtime = starttime;
// 如果当前时间减去开始时间小于5s，则一直循环。
while ((nowtime - starttime) < 5000) {
nowtime = System.currentTimeMillis();
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
log.info("task over....");
throw new RuntimeException("unexpected error , stop working");
}, 1000, 2000, TimeUnit.MILLISECONDS);
输出结果：
只有当任务执行完毕后（花费5s），等2s后，再去执行这个任务；按照这个顺序依次执行的。
详细内容看上面笔记。
阿里规范不推荐使用。但是许多中间件中有用到Timer定时类。
Timer和ScheduledThreadPool的区别，经常在面试中被问到。
Timer timer = new Timer();
// 执行第一个任务，且在任务中发生异常
timer.scheduleAtFixedRate(new TimerTask() {
@Override
public void run() {
log.info("send heart beat");
throw new RuntimeException("unexpected error , stop working");
}
},1000,2000);
// 睡眠5s后，执行第二个任务
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 执行第二个任务
timer.scheduleAtFixedRate(new TimerTask() {
@Override
public void run() {
log.info("send heart beat");
throw new RuntimeException("unexpected error , stop working");
}
},1000,2000);
执行结果：
当第一个任务发生异常的时候，该任务执行失败，Timer的线程死掉，第二个任务也不会被执行。
因为Timer是单线程的，线程都死掉了，第二个任务根本不会被执行：
private final TimerThread thread = new TimerThread(queue);
// 构造函数
public Timer() {
this("Timer-" + serialNumber());
}
public Timer(String name) {
thread.setName(name);
thread.start();
}
总结-区别（面试题）：
Timer是单线程的，在发生异常的时候，线程会死掉，即使第二个任务来了，也不会执行，可能直接导致程序挂掉。这也是为什么阿里规范不推荐使用Timer的原因，支持使用ScheduledThreadPool。 而ScheduledThreadPool创建一个核心线程，执行第一个任务异常时候，当第二个任务来的时候，线程池会再次创建线程（非核心线程）执行第二个任务。
借助第三方框架：
缺点：
适应场景：数据量小的任务。
年月日周期都在一个时间轮上。
描述：以2点为例，当时针走到2的时候（数组下标），会把2位置的链表中的所有元素取出来（任务）一起执行。这就不需要向小顶堆那样还需要比较了。
缺点：如果是13点执行任务怎么办？那么 就需要把12刻度改为24刻度。如果是13点30分执行任务怎么办？那就需要继续增加刻度，太麻烦复杂了。
年月日周期都在一个时间轮上。
第一圈的时候round=1，第二圈的时候round=1-1，取出任务执行
很明显的一个缺点：这个任务被执行的前提是一遍又一遍的遍历所有任务，round-1，
cron表达式使用的就是这个时间轮.
1-24时间轮表示一天的时间；天轮表示一天24小时
1-7时间轮表示一周七天；
1-30时间轮表示一个月；月轮表示20天
1-12时间轮表示一年；年轮表示12个月
如果是某个月的某号的某点执行某个任务，那么就需要年轮、月轮、天轮结合使用。这用的就是cron表达式。