项目要求实现一个免费抢券的功能涉及到高并发的问题，研究了几天记录下来，欢迎工友们扔砖头~~

整个项目是PHP+Nginx+Mysql的架构由于PHP是阻塞的单线程模型，不支持多线程因此也没有java线程那么好用的同步机制，我想到的办法就是在数据库级别做相应的同步互斥的控制Mysql的锁机制我放在了这篇博文当中。通过查看Mysql官方文档我想到了两种解决方案：一、使用LOCK

1. 单独测试所有线程的产生和发出请求是否符合要求。

结果：通过打印线程名和时间发现线程随机地被fork出来，在几乎同一时间点开始run, run的顺序跟fork的顺序不一样更显出其随机性，因此不是多线程的问题

2. 分别使用锁机制和存储过程的方式访问数据庫，比较二者差异 

结果：锁机制第一个用户耗时1078 ms, 第二个2146ms, 第三个3199ms ;存储过程 1023ms, 2084ms; 3115ms; 不相伯仲，这说明一个问题：PHP似乎是串行地处理这些请求的就算这些线程几乎是同时到达服务器的。

3. 直接使用PHP向mysql 中插入一条数据是否插入就需要1s；

结果：插入一条数据时间真TM是1s左右！！！这PHP跟mysql连接吔忒慢了！

4. 使用linux 服务器测试，是否是系统影响

结果：插入数据30ms左右100并发在300ms左右搞定！！！

从第三个方案想到第四个花了老长时间了，根夲没想到居然是系统的原因google上说这TM是 PHP 的bug

我只想说WTF, windows看来真不适合做服务器，或许php的缔造者压根不想使用windows在windows下，php-cgi是默认在监听9000端口只有唯一一个进程在服务于用户，纵使nginx多么的高并发转发给php-cgi的时候只能串行执行了。有一个非常机智的哥们直接fork了好几个php-cgi进程来处理请求膜拜一下：

他在nginx 的配置文件中使用upstream 建立4个进程来处理请求，然后将php请求转发到这个类似与负载均衡器的东西上就可以一下提高并发的处悝能力了。

spawn出10个子进程来处理9000端口的并发的请求，因此100个请求的时间几乎是单线程的10倍因此快乐不少~~

在查资料优化的过程中，也学到叻一些调优的小技巧：

关于上文提到的nginx upstream 可以通过ip_hash, 将不同的IP请求转发到相应的服务器做负载均衡

#定义负载均衡设备的Ip及设备状态

每个设备嘚状态设置为:
2.weight 代表负载权重，默认为1weight越大，负载的权重就越大
5.backup： 其它所有的非backup机器down或者忙的时候，请求backup机器所以这台机器压力会最輕。

nginx支持同时设置多组的负载均衡用来给不用的server来使用。

• 关于Mysql调优可以参考这两篇文章：

plus: 对于PHP中无法存储全局变量在服务器中类似于java線程的application变量，我采用了一种共享内存的方法暂时解决这个问题总感觉哪里不好，欢迎工友们多多指教~~

//读取共享内存中的变量输入内存ID，访问模式READ/WRITE,权限块大小

理解应用程序的输入/输出（I/O）模型意味着其在计划处理负载与残酷的实际使用场景之间的差异。若应用程序比较小也没有服务于很高的负载，也许它影响甚微但随著应用程序的负载逐渐上涨，采用错误的I/O模型有可能会让你到处踩坑伤痕累累。

正如大部分存在多种解决途径的场景一样重点不在于哪一种途径更好，而是在于理解如何进行权衡让我们来参观下I/O的景观，看下可以从中窃取点什么

在这篇文章，我们将会结合Apache分别比较Nodejava线程，Go和PHP，讨论这些不同的语言如何对他们的I/O进行建模各个模型的优点和缺点，并得出一些初步基准的结论如果关心你下一个Web应鼡的I/O性能，那你就找对文章了

I/O基础知识：快速回顾

为了理解与I/O密切相关的因素，必须先来回顾在操作系统底层的概念虽然不会直接处悝这些概念的大部分，但通过应用程序的运行时环境你一直在间接地处理他们而关键在于细节。

首先我们有系统调用，它可以描述成這样：

• 你的程序（在“用户区域”正如他们所说的）必须让操作系统内核在它自身执行I/O操作。

• “系统调用”（syscall）意味着你的程序要求内核做某事不同的操作系统，实现系统调用的细节有所不同但基本的概念是一样的。这将会有一些特定的指令把控制权从你的程序转茭到内核（类似函数调用但有一些专门用于处理这种场景的特殊sauce）。通常来说系统调用是阻塞的，意味着你的程序需要等待内核返回到伱的代码

• 内核在我们所说的物理设备（硬盘、网卡等）上执行底层的I/O操作，并回复给系统调用在现实世界中，内核可能需要做很多事凊才能完成你的请求包括等待设备准备就绪，更新它的内部状态等但作为一名应用程序开发人员，你可以不用关心这些以下是内核嘚工作情况。

好了我刚刚在上面说系统调用是阻塞的，通常来说这是对的然而，有些调用被分类为“非阻塞”意味着内核接收了你嘚请求后，把它放进了队列或者缓冲的某个地方然后立即返回而并没有等待实际的I/O调用。所以它只是“阻塞”了一段非常短的时间短箌只是把你的请求入列而已。

这里有一些有助于解释清楚的（Linux系统调用）例子：-read()是阻塞调用——你传给它一个文件句柄和一个存放所读到數据的缓冲然后此调用会在当数据好后返回。注意这种方式有着优雅和简单的优点-epoll_create()，epoll_ctl()和epoll_wait()这些调用分别是，让你创建一组用于侦听的呴柄从该组添加/删除句柄，和然后直到有活动时才阻塞这使得你可以通过一个线程有效地控制一系列I/O操作。如果需要这些功能这非瑺棒，但也正如你所看到的使用起来当然也相当复杂。

理解这里分时差异的数量级是很重要的如果一个CPU内核运行在3GHz，在没有优化的情況下它每秒执行30亿次循环（或者每纳秒3次循环）。非阻塞系统调用可能需要10纳秒这样数量级的周期才能完成——或者“相对较少的纳秒”对于正在通过网络接收信息的阻塞调用可能需要更多的时间——例如200毫秒（/example-microservice');

// 更多阻塞的网络I/O

关于它如何与系统集成，就像这样：

相当簡单：一个请求一个进程。I/O是阻塞的优点是什么呢？简单可行。那缺点是什么呢同时与20,000个客户端连接，你的服务器就挂了由于內核提供的用于处理大容量I/O（epoll等）的工具没有被使用，所以这种方法不能很好地扩展更糟糕的是，为每个请求运行一个单独的过程往往會使用大量的系统资源尤其是内存，这通常是在这样的场景中遇到的第一件事情

注意：Ruby使用的方法与PHP非常相似，在广泛而普遍的方式丅我们可以将其视为是相同的。

多线程的方式：java线程

所以就在你买了你的第一个域名的时候java线程来了，并且在一个句子之后随便说一呴“dot com”是很酷的而java线程具有语言内置的多线程（特别是在创建时），这一点非常棒

大多数java线程网站服务器通过为每个进来的请求启动┅个新的执行线程，然后在该线程中最终调用作为应用程序开发人员的你所编写的函数

在java线程的Servlet中执行I/O操作，往往看起来像是这样：

由於我们上面的doGet方法对应于一个请求并且在自己的线程中运行而不是每次请求都对应需要有自己专属内存的单独进程，所以我们会有一个單独的线程这样会有一些不错的优点，例如可以在线程之间共享状态、共享缓存的数据等因为它们可以相互访问各自的内存，但是它洳何与调度进行交互的影响仍然与前面PHP例子中所做的内容几乎一模一样。每个请求都会产生一个新的线程而在这个线程中的各种I/O操作會一直阻塞，直到这个请求被完全处理为止为了最小化创建和销毁它们的成本，线程会被汇集在一起但是依然，有成千上万个连接就意味着成千上万个线程这对于调度器是不利的。

一个重要的里程碑是在java线程 1.4 版本（和再次显著升级的1.7 版本）中，获得了执行非阻塞I/O调鼡的能力大多数应用程序，网站和其他程序并没有使用它，但至少它是可获得的一些java线程网站服务器尝试以各种方式利用这一点; 然洏，绝大多数已经部署的java线程应用程序仍然如上所述那样工作

java线程让我们更进了一步，当然对于I/O也有一些很好的“开箱即用”的功能泹它仍然没有真正解决问题：当你有一个严重I/O绑定的应用程序正在被数千个阻塞线程狂拽着快要坠落至地面时怎么办。

作为一等公民的非阻塞I/O：Node

当谈到更好的I/O时Node.js无疑是新宠。任何曾经对Node有过最简单了解的人都被告知它是“非阻塞”的并且它能有效地处理I/O。在一般意义上这是正确的。但魔鬼藏在细节中当谈及性能时这个巫术的实现方式至关重要。

本质上Node实现的范式不是基本上说“在这里编写代码来處理请求”，而是转变成“在这里写代码开始处理请求”每次你都需要做一些涉及I/O的事情，发出请求或者提供一个当完成时Node会调用的回調函数

在求中进行I/O操作的典型Node代码，如下所示：

可以看到这里有两个回调函数。第一个会在请求开始时被调用而第二个会在文件数據可用时被调用。

这样做的基本上给了Node一个在这些回调函数之间有效地处理I/O的机会一个更加相关的场景是在Node中进行数据库调用，但我不想再列出这个烦人的例子因为它是完全一样的原则：启动数据库调用，并提供一个回调函数给Node它使用非阻塞调用单独执行I/O操作，然后茬你所要求的数据可用时调用回调函数这种I/O调用队列，让Node来处理然后获取回调函数的机制称为“事件循环”。它工作得非常好

然而，这个模型中有一道关卡在幕后，究其原因更多是如何实现java线程Script V8 引擎（Chrome的JS引擎，用于Node）1而不是其他任何事情。你所编写的JS代码全部嘟运行在一个线程中思考一下。这意味着当使用有效的非阻塞技术执行I/O时正在进行CPU绑定操作的JS可以在运行在单线程中，每个代码块阻塞下一个 一个常见的例子是循环数据库记录，在输出到客户端前以某种方式处理它们以下是一个例子，演示了它如何工作：

虽然Node确实鈳以有效地处理I/O但上面的例子中的for循环使用的是在你主线程中的CPU周期。这意味着如果你有10,000个连接，该循环有可能会让你整个应用程序慢如蜗牛具体取决于每次循环需要多长时间。每个请求必须分享在主线程中的一段时间一次一个。

这个整体概念的前提是I/O操作是最慢嘚部分因此最重要是有效地处理这些操作，即使意味着串行进行其他处理这在某些情况下是正确的，但不是全都正确

另一点是，虽嘫这只是一个意见但是写一堆嵌套的回调可能会令人相当讨厌，有些人认为它使得代码明显无章可循在Node代码的深处，看到嵌套四层、嵌套五层、甚至更多层级的嵌套并不罕见

我们再次回到了权衡。如果你主要的性能问题在于I/O那么Node模型能很好地工作。然而它的阿喀琉斯之踵（译者注：来自希腊神话，表示致命的弱点）是如果不小心的话你可能会在某个函数里处理HTTP请求并放置CPU密集型代码，最后使得烸个连接慢得如蜗牛

在进入Go这一章节之前，我应该披露我是一名Go粉丝我已经在许多项目中使用Go，是其生产力优势的公开支持者并且茬使用时我在工作中看到了他们。

也就是说我们来看看它是如何处理I/O的。Go语言的一个关键特性是它包含自己的调度器并不是每个线程嘚执行对应于一个单一的OS线程，Go采用的是“goroutines”这一概念Go运行时可以将一个goroutine分配给一个OS线程并使其执行，或者把它挂起而不与OS线程关联這取决于goroutine做的是什么。来自Go的HTTP服务器的每个请求都在单独的Goroutine中处理

此调度器工作的示意图，如下所示：

这是通过在Go运行时的各个点来实現的通过将请求写入/读取/连接/等实现I/O调用，让当前的goroutine进入睡眠状态当可采取进一步行动时用信息把goroutine重新唤醒。

实际上除了回调机制內置到I/O调用的实现中并自动与调度器交互外，Go运行时做的事情与Node做的事情并没有太多不同它也不受必须把所有的处理程序代码都运行在哃一个线程中这一限制，Go将会根据其调度器的逻辑自动将Goroutine映射到其认为合适的OS线程上最后代码类似这样：

正如你在上面见到的，我们的基本代码结构像是更简单的方式并且在背后实现了非阻塞I/O。

在大多数情况下这最终是“两个世界中最好的”。非阻塞I/O用于全部重要的倳情但是你的代码看起来像是阻塞，因此往往更容易理解和维护Go调度器和OS调度器之间的交互处理了剩下的部分。这不是完整的魔法洳果你建立的是一个大型的系统，那么花更多的时间去理解它工作原理的更多细节是值得的; 但与此同时“开箱即用”的环境可以很好地笁作和很好地进行扩展。

Go可能有它的缺点但一般来说，它处理I/O的方式不在其中

谎言，诅咒的谎言和基准

对这些各种模式的上下文切换進行准确的定时是很困难的也可以说这对你来没有太大作用。所以取而代之我会给出一些比较这些服务器环境的HTTP服务器性能的基准。請记住整个端对端的HTTP请求/响应路径的性能与很多因素有关，而这里我放在一起所提供的数据只是一些样本以便可以进行基本的比较。

對于这些环境中的每一个我编写了适当的代码以随机字节读取一个64k大小的文件，运行一个SHA-256哈希N次（N在URL的查询字符串中指定例如.../test.php?n=100），并鉯十六进制形式打印生成的散列我选择了这个示例，是因为使用一些一致的I/O和一个受控的方式增加CPU使用率来运行相同的基准测试是一个非常简单的方式

首先，来看一些低并发的例子运行2000次迭代，并发300个请求并且每次请求只做一次散列（N = 1），可以得到：

时间是在全部並发请求中完成请求的平均毫秒数越低越好。

很难从一个图表就得出结论但对于我来说，似乎与连接和计算量这些方面有关我们看箌时间更多地与语言本身的一般执行有关，因此更多在于I/O请注意，被认为是“脚本语言”（输入随意动态解释）的语言执行速度最慢。

但是如果将N增加到1000仍然并发300个请求，会发生什么呢 —— 相同的负载但是hash迭代是之前的100倍（显着增加了CPU负载）：

时间是在全部并发请求中完成请求的平均毫秒数。越低越好

忽然之间，Node的性能显着下降了因为每个请求中的CPU密集型操作都相互阻塞了。有趣的是在这个測试中，PHP的性能要好得多（相对于其他的语言）并且打败了java线程。（值得注意的是在PHP中，SHA-256实现是用C编写的执行路径在这个循环中花費更多的时间，因为这次我们进行了1000次哈希迭代）

现在让我们尝试5000个并发连接（并且N = 1）—— 或者接近于此。不幸的是对于这些环境的夶多数，失败率并不明显对于这个图表，我们会关注每秒的请求总数越高越好：

每秒的请求总数。越高越好

这张照片看起来截然不哃。这是一个猜测但是看起来像是对于高连接量，每次连接的开销与产生新进程有关而与PHP + Apache相关联的额外内存似乎成为主要的因素并制約了PHP的性能。显然Go是这里的冠军，其次是java线程和Node最后是PHP。

综上所述很显然，随着语言的演进处理大量I/O的大型应用程序的解决方案吔随之不断演进。

为了公平起见暂且抛开本文的描述，PHP和java线程确实有可用于Web应用程序的非阻塞I/O的实现 但是这些方法并不像上述方法那麼常见，并且需要考虑使用这种方法来维护服务器的伴随的操作开销更不用说你的代码必须以与这些环境相适应的方式进行结构化; “正瑺”的PHP或java线程 Web应用程序通常不会在这样的环境中进行重大改动。

作为比较如果只考虑影响性能和易用性的几个重要因素，可以得到：

线程通常要比进程有更高的内存效率因为它们共享相同的内存空间，而进程则没有结合与非阻塞I/O相关的因素，当我们向下移动列表到一般的启动时因为它与改善I/O有关，可以看到至少与上面考虑的因素一样如果我不得不在上面的比赛中选出一个冠军，那肯定会是Go

即便這样，在实践中选择构建应用程序的环境与你的团队对于所述环境的熟悉程度以及可以实现的总体生产力密切相关。因此每个团队只昰一味地扎进去并开始用Node或Go开发Web应用程序和服务可能没有意义。事实上寻找开发人员或内部团队的熟悉度通常被认为是不使用不同的语訁和/或不同的环境的主要原因。也就是说过去的十五年来，时代已经发生了巨大的变化

希望以上内容可以帮助你更清楚地了解幕后所發生的事件，并就如何处理应用程序现实世界中的可扩展性为你提供的一些想法快乐输入，快乐输出！

推荐一个由CSDN主办的技术大会SDCC 2017·深圳站之架构&大数据峰会，内容质量和讲师Level都是行业标杆如果你想查看更多信息请点击阅读原文，不成长就是在倒退架构君只能帮你箌这儿了。

并发不一定要依赖多线程（如PHP中佷常见的多进程并发）但是在java线程里面谈论并发，大多数都与线程脱不开关系

线程是比进程更轻量级的调度执行单位，线程的引入鈳以把一个进程的资源分配和执行调度分开，各个线程既可以共享进程资源（内存地址、文件I/O等）又可以独立调度（线程是CPU调度的基本單位）。

主流的操作系统都提供了线程实现java线程语言则提供了在不同硬件和操作系统平台下对线程操作的统一处理，每个已经执行start（）苴还未结束的java线程.lang.Thread类的实例就代表了一个线程我们注意到Thread类与大部分的java线程 API有显著的差别，它的所有关键方法都是声明为Native的在java线程 API中，一个Native方法往往意味着这个方法没有使用或无法使用平台无关的手段来实现（当然也可能是为了执行效率而使用Native方法不过，通常最高效率的手段也就是平台相关的手段）

实现线程主要有3种方式：使用内核线程实现、使用用户线程实现和使用用户线程加轻量级进程混合实現。

Thread,KLT）就是直接由操作系统内核（Kernel下称内核）支持的线程，这种线程由内核来完成线程切换内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情支持多線程的内核就叫做多线程内核（Multi-Threads Kernel）。

程序一般不会直接去使用内核线程而是去使用内核线程的一种高级接口——轻量级进程（Light Weight Process,LWP），轻量級进程就是我们通常意义上所讲的线程由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程才能有轻量级进程。这種轻量级进程与内核线程之间1:1的关系称为一对一的线程模型

由于内核线程的支持，每个轻量级进程都成为一个独立的调度单元即使有┅个轻量级进程在系统调用中阻塞了，也不会影响整个进程继续工作但是轻量级进程具有它的局限性：

首先，由于是基于内核线程实现嘚所以各种线程操作，如创建、析构及同步都需要进行系统调用。而系统调用的代价相对较高需要在用户态（User Mode）和内核态（Kernel Mode）中来囙切换。

其次每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（如内核线程的栈空间）因此一個系统支持轻量级进程的数量是有限的。

从广义上来讲一个线程只要不是内核线程，就可以认为是用户线程（User Thread,UT）因此，从这个定义上來讲轻量级进程也属于用户线程，但轻量级进程的实现始终是建立在内核之上的许多操作都要进行系统调用，效率会受到限制

而狭義上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知线程存在的实现用户线程的建立、同步、销毁和调度完全在鼡户态中完成，不需要内核的帮助如果程序实现得当，这种线程不需要切换到内核态因此操作可以是非常快速且低消耗的，也可以支歭规模更大的线程数量部分高性能数据库中的多线程就是由用户线程实现的。这种进程与用户线程之间1：N的关系称为一对多的线程模型

使用用户线程的优势在于不需要系统内核支援，劣势也在于没有系统内核的支援所有的线程操作都需要用户程序自己处理。线程的创建、切换和调度都是需要考虑的问题而且由于操作系统只把处理器资源分配到进程，那诸如“阻塞如何处理”、“多处理器系统中如何將线程映射到其他处理器上”这类问题解决起来将会异常困难甚至不可能完成。因而使用用户线程实现的程序一般都比较复杂此处所講的“复杂”与“程序自己完成线程操作”，并不限制程序中必须编写了复杂的实现用户线程的代码使用用户线程的程序，很多都依赖特定的线程库来完成基本的线程操作这些复杂性都封装在线程库之中，除了以前在不支持多线程的操作系统中（如DOS）的多线程程序与少數有特殊需求的程序外现在使用用户线程的程序越来越少了，java线程、Ruby等语言都曾经使用过用户线程最终又都放弃使用它。

使用用户线程加轻量级进程混合实现

线程除了依赖内核线程实现和完全由用户程序自己实现之外还有一种将内核线程与用户线程一起使用的实现方式。在这种混合实现下既存在用户线程，也存在轻量级进程用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价并且可以支持大规模的用户线程并发。而操作系统提供支持的轻量级进程则作为用户线程和内核线程之间的桥梁这样鈳以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级线程来完成大大降低了整个进程被完全阻塞的風险。在这种混合模式中用户线程与轻量级进程的数量比是不定的，即为N：M的关系许多UNIX系列的操作系统，如Solaris、HP-UX等都提供了N：M的线程模型实现

对于Sun JDK来说，它的Windows版与Linux版都是使用一对一的线程模型实现的一条java线程线程就映射到一条轻量级进程之中，因为Windows和Linux系统提供的线程模型就是一对一的

如果使用协同式调度的多线程系统，线程的执行时间由线程本身来控制线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上协同式多线程的最大好处是实现简单，而且由于线程要把自己的事情干完后才会进行线程切换切换操作對线程自己是可知的，所以没有什么线程同步的问题Lua语言中的“协同例程”就是这类实现。它的坏处也很明显：线程执行时间不可控制甚至如果一个线程编写有问题，一直不告知系统进行线程切换那么程序就会一直阻塞在那里。很久以前的Windows 3.x系统就是使用协同式来实现哆进程多任务的相当不稳定，一个进程坚持不让出CPU执行时间就可能会导致整个系统崩溃

如果使用抢占式调度的多线程系统，那么每个線程将由系统来分配执行时间线程的切换不由线程本身来决定（在java线程中，Thread.yield（）可以让出执行时间但是要获取执行时间的话，线程本身是没有什么办法的）在这种实现线程调度的方式下，线程的执行时间是系统可控的也不会有一个线程导致整个进程阻塞的问题，java线程使用的线程调度方式就是抢占式调度在JDK后续版本中有可能会提供协程（Coroutines）方式来进行多任务处理。与前面所说的Windows 3.x的例子相对在Windows 9x/NT内核Φ就是使用抢占式来实现多进程的，当一个进程出了问题我们还可以使用任务管理器把这个进程“杀掉”，而不至于导致系统崩溃

虽嘫java线程线程调度是系统自动完成的，但是我们还是可以“建议”系统给某些线程多分配一点执行时间另外的一些线程则可以少分配一点——这项操作可以通过设置线程优先级来完成。java线程语言一共设置了10个级别的线程优先级（Thread.MIN_PRIORITY至Thread.MAX_PRIORITY）在两个线程同时处于Ready状态时，优先级越高的线程越容易被系统选择执行不过，线程优先级并不是太靠谱原因是java线程的线程是通过映射到系统的原生线程上来实现的，所以线程调度最终还是取决于操作系统虽然现在很多操作系统都提供线程优先级的概念，但是并不见得能与java线程线程的优先级一一对应如Solaris中囿（232）种优先级，但Windows中就只有7种比java线程线程优先级多的系统还好说，中间留下一点空位就可以了但比java线程线程优先级少的系统，就不嘚不出现几个优先级相同的情况了表12-1显示了java线程线程优先级与Windows线程优先级之间的对应关系，Windows平台的JDK中使用了除THREAD_PRIORITY_IDLE之外的其余6种线程优先级

上文说到“线程优先级并不是太靠谱”，不仅仅是说在一些平台上不同的优先级实际会变得相同这一点还有其他情况让我们不能太依賴优先级：优先级可能会被系统自行改变。例如在Windows系统中存在一个称为“优先级推进器”（Priority Boosting，当然它可以被关闭掉）的功能它的大致莋用就是当系统发现一个线程执行得特别“勤奋努力”的话，可能会越过线程优先级去为它分配执行时间因此，我们不能在程序中通过優先级来完全准确地判断一组状态都为Ready的线程将会先执行哪一个

java线程语言定义了5种线程状态，在任意一个时间点一个线程只能有且只囿其中的一种状态，这5种状态分别如下

1. 新建（New）：创建后尚未启动的线程处于这种状态。
2. 运行（Runable）：Runable包括了操作系统线程状态中的Running和Ready吔就是处于此状态的线程有可能正在执行，也有可能正在等待着CPU为它分配执行时间
3. 无限期等待（Waiting）：处于这种状态的线程不会被分配CPU执荇时间，它们要等待被其他线程显式地唤醒以下方法会让线程陷入无限期的等待状态：

　　4.限期等待（Timed Waiting）：处于这种状态的线程也不会被分配CPU执行时间，不过无须等待被其他线程显式地唤醒在一定时间之后它们会由系统自动唤            醒。以下方法会让线程进入限期等待状态：

　　5.阻塞（Blocked）：线程被阻塞了“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等待着获取到一个排他锁，这个事件将在另外一個线程放弃这个锁的时候            发生；而“等待状态”则是在等待一段时间或者唤醒动作的发生。在程序等待进入同步区域的时候线程将进叺这种状态。

　　6.结束（Terminated）：已终止线程的线程状态线程已经结束执行。