线程死锁、数据库死锁、慢sql、长事务等性能问题

服务器资源（cpu、内存、磁盘io、网络）是否存在性能瓶颈、是否存在队列、线程池、连接池、线程死锁、数据库死锁、慢sql、长事务等性能问题

一、队列

队列是一种常见的数据结构，也是我们学习，在计算机的世界里，基础的数据结构只有两种，一种是线性连续的存储结构–数组，还有一种是随机的存储结构—链表，很多常用的数据结构都是基于这两种基础数据结构衍生出来的，队列如它的名字，是一种先进先出(FIFO)的数据结构,在我们的实际生活或者技术方面由很广泛的应用，比如各种消息队列，阻塞队列等

二、线程池

线程池是一种多线程处理形式，处理过程中将任务添加到队列，然后在创建线程后自动启动这些任务
线程池线程都是后台线程。每个线程都使用默认的堆栈大小，以默认的优先级运行，并处于多线程单元中。如果某个线程在托管代码中空闲（如正在等待某个事件）,则线程池将插入另一个辅助线程来使所有处理器保持繁忙。如果所有线程池线程都始终保持繁忙，但队列中包含挂起的工作，则线程池将在一段时间后创建另一个辅助线程但线程的数目永远不会超过最大值，超过最大值的线程可以排队，但他们要等到其他线程完成后才启动

2.1 线程池模式

2.1.1 HS/HA半同步/半异步模式

半同步/半异步模式又称为生产者消费者模式，是比较常见的实现方式，比较简单。分为同步层、队列层、异步层三层。同步层的主线程处理工作任务并存入工作队列，工作线程从工作队列取出任务进行处理，如果工作队列为空，则取不到任务的工作线程进入挂起状态，由于线程间有数据通信，因此不适于大数据量交换的场合

2.1.2 L/F领导者与跟随者模式

领导者跟随者模式，在线程池中的线程可处在3种状态之一：领导者leader、追随者follower或工作者processor。任何时刻线程池只有一个领导者线程。事件到达时，领导者线程负责消息分离，并从处于追随者线程中选出一个来当继任领导者，然后将自身设置为工作者状态去处置该事件。处理完毕后工作者线程将自身的状态置为追随者。这一模式实现复杂，但避免了线程间交换任务数据，提高了CPU cache相似性。在ACE(Adaptive Communication Environment)中，提供了领导者跟随者模式实现

2.2 线程池的伸缩性对性能有较大的影响

创建太多线程，将会浪费一定的资源，有些线程未被充分使用。
销毁太多线程，将导致之后浪费时间再次创建它们。
创建线程太慢，将会导致长时间的等待，性能变差。
销毁线程太慢，导致其它线程资源饥饿

三、连接池

连接池是创建和管理一个连接的缓冲池的技术，这些连接准备好被任何需要它们的线程使用

3.1 连接池主要的优点

减少连接创建时间
虽然与其它数据库相比 GBase 提供了较为快速连接功能，但是创建新的 JDBC 连接仍会招致网络和 JDBC 驱动的开销。如果这类连接是“循环”使用的，使用该方式这些花销就可避免

简化的编程模式
当使用连接池时，每一个单独的线程能够像创建了一个自己的 JDBC 连接一样操作，允许用户直接使用JDBC编程技术

受控的资源使用
如果用户不使用连接池，而是每当线程需要时创建一个新的连接，那么用户的应用程序的资源使用会产生非常大的浪费并且可能会导致高负载下的异常发生。
注意，每个连到 GBase 的连接在客户端和服务器端都有花销（内存，CPU，上下文切换等等）。每个连接均会对应用程序和 GBase 服务器的可用资源带来一定的限制。不管这些连接是否在做有用的工作，仍将使用这些资源中的相当一部分

连接池能够使性能最大化，同时还能将资源利用控制在一定的水平之下，如果超过该水平，应用程序将崩溃而不仅仅是变慢

四、线程死锁

4.1 死锁概述

线程死锁是指两个或两个以上的线程互相持有对方所需要的资源，由于synchronized的特性，一个线程持有一个资源，或者说获得一个锁，在该线程释放这个锁之前，其它线程是获取不到这个锁的，而且会一直死等下去，因此这便造成了死锁

4.2 死锁产生的条件

互斥条件：一个资源，或者说一个锁只能被一个线程所占用，当一个线程首先获取到这个锁之后，在该线程释放这个锁之前，其它线程均是无法获取到这个锁的。
占有且等待：一个线程已经获取到一个锁，再获取另一个锁的过程中，即使获取不到也不会释放已经获得的锁。
不可剥夺条件：任何一个线程都无法强制获取别的线程已经占有的锁
循环等待条件：线程A拿着线程B的锁，线程B拿着线程A的锁。。

五、数据库死锁

5.1 数据库死锁具备条件

虽然进程在运行过程中，可能发生死锁，但死锁的发生也必须具备一定的条件，死锁的发生必须具备以下四个必要条件
1）互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。
2）请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
3）不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
4）环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源

5.2 产生死锁的情况

一般情况只发生锁超时，就是一个进程需要访问数据库表或者字段的时候，另外一个程序正在执行带锁的访问（比如修改数据），那么这个进程就会等待，当等了很久锁还没有解除的话就会锁超时，报告一个系统错误，拒绝执行相应的SQL操作
发生死锁的情况比较少，比如一个进程需要访问两个资源（数据库表或者字段），当获取一个资源的时候进程就对它执行锁定，然后等待下一个资源空闲，这时候如果另外一个进程也需要两个资源，而已经获得并锁定了第二个资源，那么就会死锁，因为当前进程锁定第一个资源等待第二个资源，而另外一个进程锁定了第二个资源等待第一个资源，两个进程都永远得不到满足

5.3 数据库死锁的解决方案

死锁的预防和解除：
理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配 。因此，对资源的分配要给予合理的规划

5.4 如何将死锁减至最少

虽然不能完全避免死锁，但可以使死锁的数量减至最少。将死锁减至最少可以增加事务的吞吐量并减少系统开销，因为只有很少的事务回滚，而回滚会取消事务执行的所有工作。由于死锁时回滚而由应用程序重新提交
下列方法有助于最大限度地降低死锁：
（1）按同一顺序访问对象
（2）避免事务中的用户交互
（3）保持事务简短并在一个批处理中
（4）使用低隔离级别
（5）使用绑定连接

5.4.1 按同一顺序访问对象

如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 Supplier 表上的锁，然后获得 Part 表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序

5.4.2 避免事务中的用户交互

避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。例如，如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成

5.4.3 保持事务简短并在一个批处理中

在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致死锁。
保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。

5.4.4 使用低隔离级别

确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺

5.4.5 使用绑定连接

使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞

六、慢sql：

6.1 导致慢 SQL 的原因

在遇到慢 SQL 情况时，不能简单的把原因归结为 SQL 编写问题(虽然这是最常见的因素)，实际上导致慢 SQL 有很多因素，甚至包括硬件和 mysql 本身的 bug。根据出现的概率从大到小，如下
SQL编写问题
锁
业务实例相互干绕对 IO/CPU 资源争用
服务器硬件
MYSQL BUG

6.2 由 SQL 编写导致的慢 SQL 优化

针对SQL编写导致的慢 SQL，优化起来还是相对比较方便的。正如上一节提到的正确的使用索引能加快查询速度，那么我们在编写 SQL 时就需要注意与索引相关的规则

字段类型转换导致不用索引，如字符串类型的不用引号，数字类型的用引号等，这有可能会用不到索引导致全表扫描

mysql 不支持函数转换，所以字段前面不能加函数，否则这将用不到索引

不要在字段前面加减运算

字符串比较长的可以考虑索引一部份减少索引文件大小，提高写入效率

like % 在前面用不到索引

根据联合索引的第二个及以后的字段单独查询用不到索引

不要使用 select *

排序请尽量使用升序

or 的查询尽量用 union 代替 （Innodb）

复合索引高选择性的字段排在前面

order by / group by 字段包括在索引当中减少排序，效率会更高

尽量规避大事务的 SQL，大事务的 SQL 会影响数据库的并发性能及主从同步

分页语句 limit 的问题

删除表所有记录请用 truncate，不要用 delete

不让 mysql 干多余的事情，如计算

输写 SQL 带字段，以防止后面表变更带来的问题，性能也是比较优的 ( 涉及到数据字典解析，请自行查询资料)

七、长事务：

长事务，顾名思义就是一个事务执行了很长时间仍未结束。那么一个事务执行多长时间算是长事务？这在不同的数据库产品中有不同的定义，对于informix数据库来说占用逻辑日志个数的百分比达到长事务高水位线就被定义为一个长事务，而在oracle中一个事务执行时间超过6秒钟就被认为是长事务。一般来说在一个联机事务处理系统中事务执行时间应该控制在一定范围内，如果一个事务执行时间太长，会长时间锁定某些资源，不利于并发处理，有时还会因为某些资源耗尽导致数据库挂起