多线程问题解答

创建线程有哪几种方式：

①. 继承Thread类创建线程类

定义Thread类的子类，并重写该类的run方法，该run方法的方法体就代表了线程要完成的任务。因此把run()方法称为执行体。

创建Thread子类的实例，即创建了线程对象。

调用线程对象的start()方法来启动该线程。

②. 通过Runnable接口创建线程类

定义runnable接口的实现类，并重写该接口的run()方法，该run()方法的方法体同样是该线程的线程执行体。

创建 Runnable实现类的实例，并依此实例作为Thread的target来创建Thread对象，该Thread对象才是真正的线程对象。

调用线程对象的start()方法来启动该线程。

③. 通过Callable和Future创建线程

创建Callable接口的实现类，并实现call()方法，该call()方法将作为线程执行体，并且有返回值。

创建Callable实现类的实例，使用FutureTask类来包装Callable对象，该FutureTask对象封装了该Callable对象的call()方法的返回值。

使用FutureTask对象作为Thread对象的target创建并启动新线程。

调用FutureTask对象的get()方法来获得子线程执行结束后的返回值

说一下 runnable 和 callable 有什么区别：

Runnable接口中的run()方法的返回值是void，它做的事情只是纯粹地去执行run()方法中的代码而已；

Callable接口中的call()方法是有返回值的，是一个泛型，和Future、FutureTask配合可以用来获取异步执行的结果。

线程有哪些状态：

线程通常都有五种状态，创建、就绪、运行、阻塞和死亡。

创建状态。在生成线程对象，并没有调用该对象的start方法，这是线程处于创建状态。

就绪状态。当调用了线程对象的start方法之后，该线程就进入了就绪状态，但是此时线程调度程序还没有把该线程设置为当前线程，此时处于就绪状态。在线程运行之后，从等待或者睡眠中回来之后，也会处于就绪状态。

运行状态。线程调度程序将处于就绪状态的线程设置为当前线程，此时线程就进入了运行状态，开始运行run函数当中的代码。

阻塞状态。线程正在运行的时候，被暂停，通常是为了等待某个时间的发生(比如说某项资源就绪)之后再继续运行。sleep,suspend，wait等方法都可以导致线程阻塞。

死亡状态。如果一个线程的run方法执行结束或者调用stop方法后，该线程就会死亡。对于已经死亡的线程，无法再使用start方法令其进入就绪。

sleep() 和 wait() 有什么区别：

让出执行机会给其他线程，等到休眠时间结束后，线程进入就绪状态和其他线程一起竞争cpu的执行时间。因为sleep() 是static静态的方法，他不能改变对象的机锁，当一个synchronized块中调用了sleep() 方法，线程虽然进入休眠，但是对象的机锁没有被释放，其他线程依然无法访问这个对象。

wait()：wait()是Object类的方法，当一个线程执行到wait方法时，它就进入到一个和该对象相关的等待池，同时释放对象的机锁，使得其他线程能够访问，可以通过notify，notifyAll方法来唤醒等待的线程。

notify()和 notifyAll()有什么区别：

如果线程调用了对象的 wait()方法，那么线程便会处于该对象的等待池中，等待池中的线程不会去竞争该对象的锁。

当有线程调用了对象的 notifyAll()方法（唤醒所有 wait 线程）或 notify()方法（只随机唤醒一个 wait 线程），被唤醒的的线程便会进入该对象的锁池中，锁池中的线程会去竞争该对象锁。也就是说，调用了notify后只要一个线程会由等待池进入锁池，而notifyAll会将该对象等待池内的所有线程移动到锁池中，等待锁竞争。

优先级高的线程竞争到对象锁的概率大，假若某线程没有竞争到该对象锁，它还会留在锁池中，唯有线程再次调用 wait()方法，它才会重新回到等待池中。而竞争到对象锁的线程则继续往下执行，直到执行完了 synchronized 代码块，它会释放掉该对象锁，这时锁池中的线程会继续竞争该对象锁。

使用线程池有哪些好处：

①提高系统的响应速度

②如果每次多线程操作都创建一个线程，会浪费时间和消耗系统资源，而线程池可以减少这些操作。

③可以对多个线程进行统一管理，统一调度，提高线程池的可管理性

创建线程池的参数有哪些：（7个参数）

corePoolSize：核心线程数量，默认情况下每提交一个任务就会创建一个核心线程，直到核心线程的数量等于corePoolSize就不再创建。线程池提供了两个方法可以提前创建核心线程，prestartAllCoreThreads()提前创建所有的核心线程，prestartCoreThread，提前创建一个核心线程。

maximumPoolSize：线程池允许创建的最大线程数。只有当线程池队列满的时候才会创建

keepAliveTime：线程池空闲状态可以等待的时间，默认对非核心线程生效，但是设置allowCoreThreadTimeOut的话对核心线程也生效

unit：保活时间的单位

TimeUnit.DAYS;               //天

TimeUnit.HOURS;             //时

TimeUnit.MINUTES;           //分钟

TimeUnit.SECONDS;           //秒

TimeUnit.MILLISECONDS;      //毫秒

TimeUnit.MICROSECONDS;      //微妙

TimeUnit.NANOSECONDS;       //纳秒

workQueue：任务队列，用于保持或等待执行的任务阻塞队列。BlockingQueue的实现类即可，有无界队列和有界队列

（1）ArrayBlockingQueue：基于数组结构的有界阻塞队列，按先进先出对元素进行排序。

（2）LinkedBlockingQueue：基于链表结构的有界/无界阻塞队列，按先进先出对元素进行排序，吞吐量通常高于 ArrayBlockingQueue。Executors.newFixedThreadPool 使用了该队列。

（3）SynchronousQueue：不是一个真正的队列，而是一种在线程之间移交的机制。要将一个元素放入 SynchronousQueue 中，必须有另一个线程正在等待接受这个元素。如果没有线程等待，并且线程池的当前大小小于最大值，那么线程池将创建一个线程，否则根据拒绝策略，这个任务将被拒绝。使用直接移交将更高效，因为任务会直接移交给执行它的线程，而不是被放在队列中，然后由工作线程从队列中提取任务。只有当线程池是无界的或者可以拒绝任务时，该队列才有实际价值。

（4）PriorityBlockingQueue：具有优先级的无界队列，按优先级对元素进行排序。元素的优先级是通过自然顺序或 Comparator 来定义的。

使用有界队列时，需要注意线程池满了后，被拒绝的任务如何处理。使用无界队列时，需要注意如果任务的提交速度大于线程池的处理速度，可能会导致内存溢出。

threadFactory：用于设置创建线程的工厂。

handler：拒绝策略，当队列线程池都满了，必须采用一种策略来处理还要提交的任务。在实际应用中，我们可以将信息记录到日志，来分析系统的负载和任务丢失情况JDK中提供了4种策略：

AbortPolicy策略：该策略会直接抛出异常，阻止系统正常工作。

CallerRunsPolicy 策略：只要线程池未关闭，该策略直接在调用者线程中，运行当前的被丢弃的任务。

DiscardOleddestPolicy策略： 该策略将丢弃最老的一个请求，也就是即将被执行的任务，并尝试再次提交当前任务。

DiscardPolicy策略：该策略默默的丢弃无法处理的任务，不予任何处理。

除了JDK默认提供的四种拒绝策略，我们可以根据自己的业务需求去自定义拒绝策略，自定义的方式很简单，直接实现RejectedExecutionHandler接口即可。

线程池的执行逻辑：

线程池的状态有哪些：

RUNNING：运行状态，接受新任务，持续处理任务队列里的任务。

SHUTDOWN：调用shutdown()方法会进入此状态，不再接受新任务，但要处理任务队列里的任务

STOP：调用shutdownNow()方法，不再接受新任务，不再处理任务队列里的任务，中断正在进行中的任务

TIDYING：表示线程池正在停止运作，中止所有任务，销毁所有工作线程。

TERMINATED：表示线程池已停止运作，所有工作线程已被销毁，所有任务已被清空或执行完毕。

 

 

execute和submit的区别：

execute适用于不需要关注返回值的场景，只需要将线程丢到线程池中去执行就可以了。

submit方法适用于需要关注返回值的场景。

线程池的关闭：

关闭线程池可以调用shutdownNow和shutdown两个方法来实现

shutdownNow：对正在执行的任务全部发出interrupt()，停止执行，对还未开始执行的任务全部取消，并且返回还没开始的任务列表。

shutdown：当我们调用shutdown后，线程池将不再接受新的任务，但也不会去强制终止已经提交或者正在执行中的任务。

在我们实际使用中，线程池的大小配置多少合适： 

要想合理的配置线程池大小，首先我们需要区分任务是计算密集型还是I/O密集型。对于计算密集型，设置 线程数 = CPU数 + 1，通常能实现最优的利用率。对于I/O密集型，网上常见的说法是设置 线程数 = CPU数 * 2 ，这个做法是可以的，但不是最优的。

 在我们日常的开发中，我们的任务几乎是离不开I/O的，常见的网络I/O（RPC调用）、磁盘I/O（数据库操作），并且I/O的等待时间通常会占整个任务处理时间的很大一部分，在这种情况下，开启更多的线程可以让 CPU 得到更充分的使用，一个较合理的计算公式如下：

 线程数 = CPU数 * CPU利用率 * (任务等待时间 / 任务计算时间 + 1)

 例如我们有个定时任务，部署在4核的服务器上，该任务有100ms在计算，900ms在I/O等待，则线程数约为：4 * 1 * (1 + 900 / 100) = 40个。当然，具体我们还要结合实际的使用场景来考虑。