Java与线程

java与线程

java提供了在不同硬件和操作系统环境下对线程操作的统一处理，每个已经通过start()方法且还没结束的java.lang.Thread类的实例就代表一个线程。

线程实现方式

• 使用内核线程实现（1：1实现）
  

  • 内核线程（KLT，即操作系统原生线程）定义：直接由操作系统内核支持的线程，操作系统内核负责内核线程的切换，内核通过操控调度器对线程进行调度，并负责将** 线程的任务映射**到各个处理器上。
  • 内核线程提供一种高级接口–轻量级进程（LWP–给应用程序使用，每个轻量级进程都由一个内核线程支持（1:1关系），轻量级进程就是通常意义上的线程。
  • 优势：由于每条轻量级进程都有一条内核线程支持，故每个轻量级进程都是一个独立的调度单元，及时其中某个轻量级进程在系统调用中被阻塞，也不会影响整个进程继续工作。
  • 缺点：（1）性能低：轻量级进程的各种操作如创建、销毁、调度等都需要进行系统调用，而系统调用需要在用户态和内核态之间来回切换，代价很高。（2）消耗资源：一个系统支持轻量级进程的数量是有限的，因为每个轻量级进程都需和内核中的内核线程对应。

• 使用用户线程实现（1：N实现）
  

  • 用户线程（UT）定义：用户线程完全建立在用户空间的线程库上，系统内核无法感知用户线程。用户线程建立、同步、销毁和调度都是在用户态，不需要内核帮助。
  • 优势：用户线程实现不需要内核支持，即不用进行系统调用，所以操作速度快效率高且可以支持大规模线程数量。
  • 缺点：由于没有内核支持，所有的线程操作都需要用户程序自己实现，相当困难。

• 使用用户线程+轻量级线程实现（N：M实现）
  

  • 这种混合模式下，用户线程还是完全建立在用户空间中，因此用户线程创建、切换、销毁、等操作依然廉价，并且可以支持大规模用户线程并发。而轻量级线程作为用户线程与内核线程之间的桥梁，这样用户线程可以使用内核提供的调度及处理器映射功能，并且用户线程的系统调用通过轻量级进程完成，降低了整个进程被完全阻塞的风险。这种模式中用户线程与轻量级进程的数量比不是一定的。

• java线程实现方式

  • jdk1.3开始，主流java虚拟机采用基于内核线程实现java线程，即java线程与内核线程是1:1关系，每条java线程都直接映射到操作系统原生线程，且中间没有额外的间接结构，故java线程的管理完全交给操作系统内核。操作系统决定何时冻结或者唤醒线程、该给线程分配多少处理器时间、该把线程安排给哪个处理器核心执行等都是由操作系统决定

java线程调度

线程调度是指系统为线程分配处理器使用权的过程，一个分为两种：

• 协同式线程调度
  • 定义：线程占用cpu时间由线程本身决定，线程执行完毕后才释放cpu资源，执行期间其他线程不能抢占cpu资源，执行完毕后主动通知系统切换到另一个线程上去。
  • 优势： 实现简单；而且由于线程把自己的事情结束后才进行线程切换，这个切换操作对线程自己是可知的，因此一般没有线程同步的问题。
  • 劣势：线程执行时间不可控，有可能一个正在执行的线程一直被阻塞，一直没有通知进行线程切换，此时其他线程又不能获得cpu资源（由于当前线程还没有执行完毕），那么整个系统会崩溃。
• 抢占式线程调度–java采用该中线程调度方式
  • 定义：每个线程由系统分配执行时间，线程切换不由线程本身来决定。比如：Thread::yield()方法主动让出cpu资源。
  • 优势：这种线程调度方式是系统可控的，不会因为一个线程长时间不释放cpu资源而导致整个系统阻塞。

java线程优先级
java语言一共设置了10个级别的线程优先级（1–10）。在两个线程同时处于Ready状态时，优先级高的线程越容易被系统进行选择。
线程优先级不是一项稳定的调节线程先后执行的手段。理由如下：
（1）java线程的优先级可能不与各个操作系统的线程优先级一一对应。如windows系统只支持7中优先级。如果系统优先级少于java优先级个数，那么就会出现几个线程优先级对应同一个系统优先级。 如图，如java中1、2优先级对应windows系统中同一优先级。1、2； 3、4； 5； 6、7； 8、9； 10

（2）线程优先级可能被系统改变。如windows中存在一个叫“优先级推进器”功能，可以越过优先级去为一个执行非常平凡的线程分配cpu资源，以此来减少因为线程频繁切换而带来的性能损耗。

java线程的状态转换

一共定义了6中线程状态，并且可以通过特定方法使得线程在不同状态间转换。

• 新建（New）：线程创建后尚未启动的线程。即知识new了一个Thread对象，还没有调用start()方法。
• 运行(Runnable)：该阶段包括操作系统线程状态中的Ready和Running，即该状态下线程可能等待分配CPU资源（Ready），或者该线程正在执行（Running）。
• 无限等待（Waiting）：该状态下线程需要等待其他线程显示唤醒自己，否则不会被分配CPU资源。导致该状态的操作有：
  • 没有设置Timeout参数的Object::wait()方法。
  • 没有设置Timeout参数的Thread::join()方法，join的底层也会用Object::wait()方法实现。
  • LockSupport::park()方法
• 有限等待（Timed Waiting）：该状态下无需等待其他线程显示唤醒自己，而是在一定时间之后该状态下线程会由系统自动唤醒。以下方法会导致该状态：
  • Thread::sleep()方法
  • 设置了Timeout参数的Object::wait()方法
  • 设置了Timeout参数的Thread::join()方法
  • LockSupport::parkNanos()方法
  • LockSupport::parkUntil()方法
• 阻塞（Blocked）：线程被阻塞，该状态与等待状态的区别是，“阻塞状态”在等待着获取到一个排他锁，而“”是在等待一段时间，或者唤醒动作的发生。程序等待进入同步区域的时候，线程将进入阻塞状态。
• 结束（Terminated）：已终止线程的线程状态，线程已经结束执行。

java与协程

内核线程的局限性

• 目前Web应用的要求：如今B/S 系统中一次对外部业务请求的响应，往往需要分布在不同机器上的大量服务共同协作来实现，这这服务细分架构一方面减少单个服务复杂度、增加复用性的同时，也不可避免地增加了服务数量，缩短了留给每个服务的响应时间。这要求每个服务必须在极短时间内完成计算，这样组合多个服务的总耗时才不会太长；也要求一个服务提供者要能同时处理数量庞大的请求，这样才不会出现请求由于某个服务被阻塞而出现等待。
• 内核线程的局限性：1:1的内核线程模型的天然缺陷是切换、调度成本高昂，系统能够容纳的线程数量也有限，如今的微服务中每个请求本身的执行时间变得很短、数量变得很多，用户线程切换的开销甚至可能接近于计算本身的开销，这造成严重的浪费。
• 为什么内核线程调度成本高昂？
  内核线程的调度成本主要来自于用户态和核心太之间的状态转换，这两种状态转换的开销主要来自于响应中断、保护和恢复执行现场的成本。如发生如下线程切换（线程A切换为线程B）
  线程A——》系统中断-------》线程B
  物理存储设备和寄存器被系统内所有线程共享，当发生中断时，线程A切换为B之前，操作系统首先把A的上下文数据保管好，然后把寄存器、内存分页等恢复到线程B挂起时候的状态。这种保护和恢复线程工作涉及一系列的数据在各种寄存器、缓存中来回拷贝，是重量级的操作。
• 传统的java Web服务器的线程池容量通常在几十个到200之间，把数以百万的请求往线程池中灌时，系统即使能够处理得过来，但其中的切换损耗也是相当客观的。

协程

• 定义：调度方式为协同式调度的用户线程为协程。
• 协程优势：轻量级。64Linux上Hotspot的虚拟机栈容量默认为1MB（可以通过-Xss或者-XX:ThreadStackSize指定），此外内核数据结构还会额外消耗16KB内存（因为每个java线程与一个内核线程对应，内核线程要占内存）。与之相对应，一个协程的栈通常在几百B到几KB之间。java虚拟机里线程池容量达到两百已经不算小了（一个线程必须有一个虚拟机栈，那么200个线程就得用200M内存来创建虚拟机栈），而在支持协程的应用中，同时并存的协程数量个数以十万计。
• 协程局限：（1）需要在应用层面实现很多，如划分内存构建调用栈、构建调度器等。（2）线程调度方式为协同式调度。
• 对于有栈协程，有一种特例实现叫纤程------java利用纤程来应对目前java线程模型（1:1模型）在微服务环境下的局限性