数据库死锁

1. Lock API 1. Locks 包类层次结构 2. Lock 接口 方法签名 描述 void lock(); 获取锁(不死不休) boolean tryLock(); 获取锁(浅尝辄止) boolean tryLock(long time, TimeUnit unit) throws InterruptedException; 获取锁(过时不候) void lockInterruptibly() throws InterruptedException; 获取锁(任人摆布) void unlock(); 释放锁 Condition newCondition(); 结论: lock() 最常用，并且线程不会被中断； lockInterruptibly() 方法一般更昂贵，有的 impl 可能没有实现 lockInterruptibly()，只有真的需要效应中断时，才使用，使用之前看看 impl 对该方法的描述。 public class Demo1_GetLock { // 公平锁 // static Lock lock = new ReentrantLock(true); // 非公平锁 static Lock lock = new ReentrantLock(); public static void main(String[] args) throws

如何并发的访问数据库呢？答案就是 加锁 。 接下来说一下， 数据库的锁机制，数据库中都有哪些锁？ 　　 首先呢，锁是一种 并发控制技术 ，锁是用来在多个用户同时访问同一个数据的时候保护数据的。 有2种基本的锁类型： 　　 共享（S）锁： 多个事务可封锁一个共享页；任何事务都不能修改该页；通常是该页被读取完毕，S锁立即被释放。在执行select语句的时候需要给操作对象（表或一些记录）加上共享锁，但加锁之前需要检查是否有排他锁，如果没有，则可以加共享锁（一个对象上可以加N个共享锁），否则不行。共享锁通常在执行完select语句之后被释放，当然也可能是在事务结束（包括正常结束和异常结束）的时候被释放，主要取决与数据库所设置的事务隔离级别。 　　 排它（X）锁： 仅允许一个事务封锁此页；其他任何事务必须等到X锁被释放才能对该页进行访问；X锁一直到事务结束才能被释放。执行insert、update、delete语句的时候需要给操作的对象加排它锁，在加排他锁之前必须确认该对象上没有其他任何锁，一旦加上排它锁之后，就不能再给这个对象加其他任何锁。排它锁的释放通常是在事务结束的时候（当然也有例外，就是在数据库事务隔离级别被设置为Read Uncommitted（读未提交数据）的时候，这种情况下排他锁会在执行完更新操作之后被释放，而不是在事务结束的时候）。 按锁的机制 既然使用了锁

第二部分: 基本同步 同步要点 到目前为止，我们已经描述了如何在线程上启动任务，配置线程以及双向传递数据。我们还描述了局部变量如何专用于线程，以及如何在线程之间共享引用，从而允许它们通过公共字段进行通信。 下一步是同步：协调线程的动作以实现可预测的结果。当线程访问相同的数据时，同步特别重要。在该区域搁浅非常容易。 同步构造可以分为四类： 简单的组织方法 它们等待另一个线程完成或等待一段时间。 Sleep，Join和Task.Wait是简单的阻止方法。 锁定构造 这些限制了可以一次执行某些活动或一次执行一段代码的线程数。排它锁定结构是最常见的-一次仅允许一个线程，并且允许竞争线程访问公共数据而不会互相干扰。标准的排他锁定结构是锁（Monitor.Enter / Monitor.Exit），互斥锁和SpinLock。非排他的锁定构造是Semaphore，SemaphoreSlim和读取器/写入器锁定 信号结构 这些允许线程暂停，直到接收到来自另一个线程的通知为止，从而避免了无效的轮询。常用的信号设备有两种：事件等待句柄和监视器的等待/脉冲方法。 Framework 4.0引入了CountdownEvent和Barrier类。 非阻塞同步构造 这些通过调用处理器原语来保护对公共字段的访问。 CLR和C＃提供以下非阻塞构造：Thread.MemoryBarrier，Thread

在讨论锁之前，可能会引入事务的隔离级别。尴尬的说，有点忘记了。 数据库死锁相对还比较常见，突然也让我想到了 goroutine 的 deadlock 。说下我的理解：死锁，其实是一种无尽的相互等待。 尝试通俗地描述一下死锁的过程： 路人甲和路人乙合租，两人公用一个卫生间 早上，路人甲醒的早，直接去了卫生间，但没有带手纸。想等路人乙醒了之后给他送手纸 路人乙起床后，拿上了手纸，想等路人甲赶紧从卫生间出来 昨晚，线上环境又 deadlock 报警。遗憾的是，虽然我知道发生死锁的原因，但不知道原因的原因。最后还是根据 DBA 同事提供的日志得出了判断。 在分析之前，先通过如下表格，了解一下数据库常见的锁： X IX S IS X Conflict Conflict Conflict Conflict IX Conflict Compatible Conflict Compatible S Conflict Conflict Compatible Compatible IS Conflict Compatible Compatible Compatible 简化描述一下，昨晚线上死锁的情况。下面对语句做了简化： 事务一 update friends set name = "道道法" where id = 1 事务二 update friends set name = "道道法" where

死锁（Deadlock）：是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。例如，如果线程A锁住了记录1并等待记录2，而线程B锁住了记录2并等待记录1，这样两个线程就发生了死锁现象。 产生死锁的原因主要是： （1）系统资源不足。 （2）进程运行推进的顺序不合适。 （3）资源分配不当等。 如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。 产生死锁的四个必要条件： （1） 互斥条件：一个资源每次只能被一个进程使用。 （2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。 （3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。 （4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。 这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。 死锁的预防和解除： 1、 如何确定资源的合理分配算法，避免进程永久占据系统资源 2、防止进程在处于等待状态的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查

Java并发学习笔记(一）锁 前言 在多线程环境中，如果对共享变量进行非原子的操作，就很可能出现线程安全问题，为了维护多线程环境下操作共享变量的数据一致性，通常我们就需要用到锁，在Java中，关于锁的概念很多，在学习的过程中整理了一部分简单给大家分享一下。 锁名词概念 死锁、活锁、饥饿锁、无锁 悲观锁、乐观锁 偏向锁、轻量级锁、重量级锁 重入锁 非公平锁、公平锁 独占锁、共享锁 读写锁 以上锁相关名词有的指锁的状态，有的是锁的设计思想，还有一些锁实现相关的特性等等，一些名词之间存在强关联，不是很好分类，下面逐步进行展开说明。 死锁 死锁原因 多个线程竞争共享资源，由于抢占顺序不一致导致线程间互相等待对方持有的资源释放，导致线程永久阻塞等待。 死锁条件 互斥条件：共享资源只能同时被一个线程占用 请求与保持条件：线程1已经取得共享资源X，在等待共享资源Y的时候，不释放共享资源X 不可剥夺条件：线程1占有的共享资源，其他线程不能强行抢占 循环等待条件：线程1等待线程2占有的资源，线程2等待线程1占有的资源，就是互相等待 如何避免死锁 不使用锁或者不使用两把及以上的锁 必须使用两把及以上的锁时，保证整个应用获取锁的顺序一致 尝试获取具有超时释放的锁，比如tryLock 当发生Java-Level的死锁时，重启程序干掉进程或者线程，比如数据库事务 如何定位死锁 jps及jstack命令定位

原文: 高性能MySQL之锁详解 一、背景 MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。数据库锁的设计的初衷是处理并发问题。我们知道多用户共享资源的时候，就有可能会出现并发访问的时候，数据库就需要合理的控制资源的访问规则，因此，锁就应运而生了，它主要用来实现这些访问规则的重要数据结构。 二、全局锁 顾名思义，全局锁就是对整个数据库实例加锁，可以通过命令 Flush tables with read lock (FTWRL)对整个数据库实例子加锁。让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。 全局锁有一个经典的使用场景就是做全库逻辑备份，也就是说吧整个数据库的每个表都用select 出来存成文本。以前有一种做法是通过FTWRL确保不会有其他线程对数据库做更新，然后对整个库做备份。注意，在备份过程中整个库完全处于只读状态。 你此时是不是觉得很危险？ 如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆； 如果你在从库上备份，那么备份期间从库不能执行主库同步过来的binlog，会导致主从延迟。 看上去确实很危险，但是我们细想一下，备份为什么要加锁呢？如果我们不加锁又会出现什么问题呢？ 假设你现在要维护京东的购买系统

一、背景 MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。数据库锁的设计的初衷是处理并发问题。我们知道多用户共享资源的时候，就有可能会出现并发访问的时候，数据库就需要合理的控制资源的访问规则，因此，锁就应运而生了，它主要用来实现这些访问规则的重要数据结构。 二、全局锁 顾名思义，全局锁就是对整个数据库实例加锁，可以通过命令 Flush tables with read lock (FTWRL)对整个数据库实例子加锁。让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。 全局锁有一个经典的使用场景就是做全库逻辑备份，也就是说吧整个数据库的每个表都用select 出来存成文本。以前有一种做法是通过FTWRL确保不会有其他线程对数据库做更新，然后对整个库做备份。注意，在备份过程中整个库完全处于只读状态。 你此时是不是觉得很危险？ 如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆； 如果你在从库上备份，那么备份期间从库不能执行主库同步过来的binlog，会导致主从延迟。 看上去确实很危险，但是我们细想一下，备份为什么要加锁呢？如果我们不加锁又会出现什么问题呢？ 假设你现在要维护京东的购买系统，关注的是用户账户余额表和用户商品表。

近日向领导汇报工作时，发现自己工作两年多来，在技能提升方面，始终是基于需求驱动，自主学习的觉悟比较不足，于是在网上搜索汇总得到以下java技能提升的一些知识点，粗略扫了一遍，发现一知半解甚至没有接触过的内容比较多，始知自身所掌握之局限。便开通了这个CSDN账号，计划在日后工作之余，有选择地研究下面的一些重要知识点。每次学习所得的内容，我会另开文章记录学习过程中的思考、疑惑、结论等，供自己日后回顾，若能惠及他人，也是我的荣幸。希望能够坚持下去。 一、基础篇 面向对象 什么是面向对象 面向对象、面向过程 面向对象的三大基本特征和五大基本原则 平台无关性 Java如何实现的平台无关 JVM还支持哪些语言（Kotlin、Groovy、JRuby、Jython、Scala） 值传递 值传递、引用传递 为什么说Java中只有值传递 封装、继承、多态 什么是多态、方法重写与重载 Java的继承与实现 构造函数与默认构造函数 类变量、成员变量和局部变量 成员变量和方法作用域 Java基础知识 基本数据类型 7种基本数据类型：整型、浮点型、布尔型、字符型 整型中byte、short、int、long的取值范围 什么是浮点型？什么是单精度和双精度？为什么不能用浮点型表示金额？ 自动拆装箱 什么是包装类型、什么是基本类型、什么是自动拆装箱 Integer的缓存机制 String 字符串的不可变性 JDK

1.交叉锁会导致程序死锁 这个大家都很熟悉了，就是线程A持有R1的锁又想获取R2的锁，线程B持有R2的锁又想获取R1的锁。两个谁也不放弃自己的又想要对方的，就导致死锁了。 一般交叉引起的死锁线程都会进入BLOCKED状态，CPU资源占用不高，可以借助jstack或jconsole工具诊断。 2.内存不足 如两个线程A和B执行某个任务，A已获取10MB内存，B已获取20MB内存，它们执行都需要30MB的内存，但剩余可用的内存不够30MB了，两个线程就有可能都在等待彼此释放内存资源。 3.C/S数据交换 服务端开启某端口，等待客户端访问，客户端发送请求立即等待接收，由于某种原因服务端错过了客户端的请求，仍在等待，就会陷入双方都在等待对方发送数据。 4.数据库锁 表级别或行级别锁，比如某个线程执行for update 语句退出了事务，其他线程访问该数据库时都将陷入死锁。 5.死循环引起的死锁（系统假死） HashMap是线程不安全的，它的put方法会陷入死循环，具体原因参考 并发HashMap的put操作引起死循环 。 死循环会导致程序假死，不是真正的死锁，但某个线程对CPU消耗过多，导致其他线程等待CPU，内存等资源就也会陷入死锁等待。 来源： CSDN 作者： ziyonghong 链接： https://blog.csdn.net/ziyonghong/article