auto commit
This commit is contained in:
parent
07b42a4e63
commit
34876d1576
|
@ -19,7 +19,6 @@
|
|||
* [结束线程](#结束线程)
|
||||
* [1. 阻塞](#1-阻塞)
|
||||
* [2. 中断](#2-中断)
|
||||
* [Java 并发工具包](#java-并发工具包)
|
||||
* [线程状态转换](#线程状态转换)
|
||||
* [内存模型](#内存模型)
|
||||
* [1. 硬件的效率与一致性](#1-硬件的效率与一致性)
|
||||
|
@ -396,10 +395,6 @@ interrupt() 方法会设置中断状态,可以通过 interrupted() 方法来
|
|||
|
||||
interrupted() 方法在检查完中断状态之后会清除中断状态,这样做是为了确保一次中断操作只会产生一次影响。
|
||||
|
||||
# Java 并发工具包
|
||||
|
||||
> [JDK 并发包 1](https://www.ibm.com/developerworks/cn/java/java-lo-concurrenthashmap/)
|
||||
|
||||
# 线程状态转换
|
||||
|
||||
<div align="center"> <img src="../pics//38b894a7-525e-4204-80de-ecc1acc52c46.jpg"/> </div><br>
|
||||
|
|
|
@ -1,18 +1,18 @@
|
|||
<!-- GFM-TOC -->
|
||||
* [事务四大特性](#事务四大特性)
|
||||
* [原子性](#原子性)
|
||||
* [一致性](#一致性)
|
||||
* [隔离性](#隔离性)
|
||||
* [持久性](#持久性)
|
||||
* [1. 原子性](#1-原子性)
|
||||
* [2. 一致性](#2-一致性)
|
||||
* [3. 隔离性](#3-隔离性)
|
||||
* [4. 持久性](#4-持久性)
|
||||
* [数据不一致](#数据不一致)
|
||||
* [丢失修改](#丢失修改)
|
||||
* [读脏数据](#读脏数据)
|
||||
* [不可重复读](#不可重复读)
|
||||
* [1. 丢失修改](#1-丢失修改)
|
||||
* [2. 读脏数据](#2-读脏数据)
|
||||
* [3. 不可重复读](#3-不可重复读)
|
||||
* [隔离级别](#隔离级别)
|
||||
* [未提交读(READ UNCOMMITTED)](#未提交读read-uncommitted)
|
||||
* [提交读(READ COMMITTED)](#提交读read-committed)
|
||||
* [可重复读(REPEATABLE READ)](#可重复读repeatable-read)
|
||||
* [可串行化(SERIALIXABLE)](#可串行化serialixable)
|
||||
* [1. 未提交读(READ UNCOMMITTED)](#1-未提交读read-uncommitted)
|
||||
* [2. 提交读(READ COMMITTED)](#2-提交读read-committed)
|
||||
* [3. 可重复读(REPEATABLE READ)](#3-可重复读repeatable-read)
|
||||
* [4. 可串行化(SERIALIXABLE)](#4-可串行化serialixable)
|
||||
* [可串行化调度](#可串行化调度)
|
||||
* [封锁类型](#封锁类型)
|
||||
* [封锁粒度](#封锁粒度)
|
||||
|
@ -52,53 +52,55 @@
|
|||
|
||||
# 事务四大特性
|
||||
|
||||
## 原子性
|
||||
## 1. 原子性
|
||||
|
||||
要么都执行,要么都不执行。
|
||||
事务被视为不可分割的最小单元,要么全部提交成功,要么全部失败回滚。
|
||||
|
||||
## 一致性
|
||||
## 2. 一致性
|
||||
|
||||
事务执行前后都保持一致性状态。在一致性状态下,所有事务对一个数据的读取结果都是相同的。
|
||||
|
||||
## 隔离性
|
||||
## 3. 隔离性
|
||||
|
||||
多个事务单独执行,互不影响。
|
||||
一个事务所做的修改在最终提交以前,对其它事务是不可见的。也可以理解为多个事务单独执行,互不影响。
|
||||
|
||||
## 持久性
|
||||
## 4. 持久性
|
||||
|
||||
即使系统发生故障,事务执行的结果也不能丢失。持久性通过数据库备份和恢复来保证。
|
||||
一旦事务提交,则其所在的修改将会永远保存到数据库中。即使系统发生崩溃,事务执行的结果也不能丢失。持久性通过数据库备份和恢复来保证。
|
||||
|
||||
# 数据不一致
|
||||
|
||||
## 丢失修改
|
||||
## 1. 丢失修改
|
||||
|
||||
T<sub>1</sub> 和 T<sub>2</sub> 两个事务同时对一个数据进行修改,T<sub>1</sub> 先修改,T<sub>2</sub> 随后修改,T<sub>2</sub> 的修改覆盖了 T<sub>1</sub> 的修改。
|
||||
|
||||
## 读脏数据
|
||||
## 2. 读脏数据
|
||||
|
||||
T<sub>1</sub> 做修改后写入数据库,T<sub>2</sub> 读取这个修改后的数据,但是如果 T<sub>1</sub> 撤销了这次修改,使得 T<sub>2</sub> 读取的数据是脏数据。
|
||||
|
||||
## 不可重复读
|
||||
## 3. 不可重复读
|
||||
|
||||
T<sub>1</sub> 读入某个数据,T<sub>2</sub> 对该数据做了修改,如果 T<sub>1</sub> 再读这个数据,该数据已经改变,和最开始读入的是不一样的。
|
||||
|
||||
# 隔离级别
|
||||
|
||||
数据库管理系统需要防止数据出现不一致,并且有多种级别可以实现,这些级别称为隔离级别。
|
||||
数据库管理系统需要防止出现数据不一致问题,并且有多种级别可以实现,这些级别称为隔离级别。
|
||||
|
||||
## 未提交读(READ UNCOMMITTED)
|
||||
## 1. 未提交读(READ UNCOMMITTED)
|
||||
|
||||
一个事务可以读取其它事务的未提交数据,也被称为脏读。
|
||||
事务中的修改,即使没有提交,对其它事务也都是可见的。事务可以读取未提交的数据,这也被称为脏读。
|
||||
|
||||
## 提交读(READ COMMITTED)
|
||||
## 2. 提交读(READ COMMITTED)
|
||||
|
||||
一个事务可以读取其它事务的已提交数据,但是该数据可能过后就会被其它事务改变,因此也称为不可重复读。
|
||||
一个事务只能读取已经提交的事务所做的修改。换句话说,一个事务所在的修改在提交之前对其它事务使不可见的。这个级别有时候也叫做不可重复读,因为两次执行同样的查询,可能会得到不一样的结果。
|
||||
|
||||
## 可重复读(REPEATABLE READ)
|
||||
## 3. 可重复读(REPEATABLE READ)
|
||||
|
||||
保证在同一个事务中多次读取同样的记录结果是一致的。但是会出现幻读的问题,所谓幻读,指的是某个事务在读取某个范围内的记录时,其它事务会在范围内插入数据,产生幻行。
|
||||
解决了脏读的问题,保证在同一个事务中多次读取同样的记录结果是一致的。
|
||||
|
||||
## 可串行化(SERIALIXABLE)
|
||||
但是会出现幻读的问题,所谓幻读,指的是某个事务在读取某个范围内的记录时,另一个事务会在范围内插入数据,当之前的事务再次读取该范围的记录时,会产生幻行。
|
||||
|
||||
## 4. 可串行化(SERIALIXABLE)
|
||||
|
||||
强制事务串行执行,避免幻读。
|
||||
|
||||
|
@ -108,17 +110,20 @@ T<sub>1</sub> 读入某个数据,T<sub>2</sub> 对该数据做了修改,如
|
|||
|
||||
# 封锁类型
|
||||
|
||||
排它锁 (X 锁),共享锁 (S 锁)
|
||||
排它锁 (X 锁)和共享锁 (S 锁),又称写锁和读锁。
|
||||
|
||||
一个事务 T 对数据对象 A 加了 X 锁,T 就可以对 A 进行读取和更新。加锁期间其它事务不能对数据对象 A 加任何其它锁;
|
||||
- 一个事务对数据对象 A 加了 X 锁,就可以对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何其它锁;
|
||||
|
||||
- 一个事务对数据对象 A 加了 S 锁,可以对 A 进行读取操作,但是不能进行更新操作。加锁期间其它事务能对 A 加 S 锁,但是不能加 X 锁。
|
||||
|
||||
一个事务 T 对数据对象加了 S 锁,T 可以对 A 进行读取操作,但是不能进行更新操作。加锁期间其它事务能对数据对象 A 加 S 锁,但是不能加 X 锁。
|
||||
|
||||
# 封锁粒度
|
||||
|
||||
粒度可以是整个数据库,也可以是表,行,或者分量。
|
||||
应该尽量只锁定需要修改的部分数据,而不是所有的资源。锁定的数据量越少,发生锁争用的可能就更小,则系统的并发程度越高。
|
||||
|
||||
粒度越大,开销越大。
|
||||
但是加锁需要消耗资源,锁的各种操作,包括获取锁,检查所是否已经解除、释放锁,都会增加系统开销。因此需要在锁开销以及数据安全性之间做一个权衡。
|
||||
|
||||
MySQL 中主要提供了两种锁粒度:行解锁以及表级锁。
|
||||
|
||||
# 封锁协议
|
||||
|
||||
|
@ -347,4 +352,5 @@ Entity-Relationship,包含三个部分:实体、属性、联系。
|
|||
# 参考资料
|
||||
|
||||
- 史嘉权. 数据库系统概论[M]. 清华大学出版社有限公司, 2006.
|
||||
- 施瓦茨. 高性能MYSQL(第3版)[M]. 电子工业出版社, 2013.
|
||||
- [MySQL 乐观锁与悲观锁 ](https://www.jianshu.com/p/f5ff017db62a)
|
||||
|
|
|
@ -5,6 +5,12 @@
|
|||
* [3. 里氏替换原则](#3-里氏替换原则)
|
||||
* [4. 接口分离原则](#4-接口分离原则)
|
||||
* [5. 依赖倒置原则](#5-依赖倒置原则)
|
||||
* [其他常见原则](#其他常见原则)
|
||||
* [1. 迪米特法则](#1-迪米特法则)
|
||||
* [2. 合成复用原则](#2-合成复用原则)
|
||||
* [3. 共同封闭原则](#3-共同封闭原则)
|
||||
* [4. 稳定抽象原则](#4-稳定抽象原则)
|
||||
* [5. 稳定依赖原则](#5-稳定依赖原则)
|
||||
* [封装、继承、多态](#封装继承多态)
|
||||
* [1. 封装](#1-封装)
|
||||
* [2. 继承](#2-继承)
|
||||
|
@ -50,6 +56,38 @@ S.O.L.I.D 是面向对象设计和编程 (OOD&OOP) 中几个重要编码原则 (
|
|||
1. 高层模块不应该依赖于低层模块,二者都应该依赖于抽象
|
||||
2. 抽象不应该依赖于细节,细节应该依赖于抽象
|
||||
|
||||
# 其他常见原则
|
||||
|
||||
除了上述的经典原则,在实际开发中还有下面这些常见的设计原则。
|
||||
|
||||
| 简写 | 全拼 | 中文翻译 |
|
||||
| -- | -- | -- |
|
||||
|LoD| The Law of Demeter | 迪米特法则 |
|
||||
|CRP| The Composite Reuse Principle | 合成复用原则 |
|
||||
|CCP| The Common Closure Principle | 共同封闭原则 |
|
||||
|SAP| The Stable Abstractions Principle | 稳定抽象原则 |
|
||||
|SDP| The Stable Dependencies Principle | 稳定依赖原则 |
|
||||
|
||||
## 1. 迪米特法则
|
||||
|
||||
迪米特法则又叫作最少知道原则(Least Knowledge Principle 简写LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
|
||||
|
||||
## 2. 合成复用原则
|
||||
|
||||
尽量使用对象组合,而不是继承来达到复用的目的。
|
||||
|
||||
## 3. 共同封闭原则
|
||||
|
||||
一起修改的类,应该组合在一起(同一个包里)。如果必须修改应用程序里的代码,我们希望所有的修改都发生在一个包里(修改关闭),而不是遍布在很多包里。
|
||||
|
||||
## 4. 稳定抽象原则
|
||||
|
||||
最稳定的包应该是最抽象的包,不稳定的包应该是具体的包,即包的抽象程度跟它的稳定性成正比。
|
||||
|
||||
## 5. 稳定依赖原则
|
||||
|
||||
包之间的依赖关系都应该是稳定方向依赖的,包要依赖的包要比自己更具有稳定性。
|
||||
|
||||
# 封装、继承、多态
|
||||
|
||||
封装、继承、多态是面向对象的三大特性。
|
||||
|
|
Loading…
Reference in New Issue
Block a user