对比了 jdk 中的 lock 和 mysql 的锁

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2675 天前的主题，其中的信息可能已经有所发展或是发生改变。

发现 lock 和 mysql 的独占锁共享锁提升性能的思路一样。哈哈，在高层次的思想都是一样。

第 1 条附言 · 2017-07-30 12:15:58 +08:00

在 jdk 中的读写锁，和 myql 的读写锁。在执行并发时，都使用读写锁的思想。在大多数并发程序在读锁和写都是分离的。从而提升并发程序的执行率，减少线程的冲突。在 jdk 并发包中的很多类也是这样思想。

第 2 条附言 · 2017-07-30 18:00:54 +08:00

mysql 使用 innodb 事务设置 Repeatable Read(可重读)

8 条回复 • 2017-07-31 01:14:35 +08:00

CryMeatel

2017-07-30 13:38:58 +08:00 via Android

读的话，为啥要加锁

ihuotui

2017-07-30 14:11:11 +08:00 via iPhone

@CryMeatel java 要同步数据，mysql 中复杂一些，并发中的事务保证 acid 又性能最好，mysql 建议看看书或者手册。

RLib

2017-07-30 15:31:04 +08:00

本来就是这么回事，有人在读你就不能写但能读，有人在写大家都不能读也不能写，以往普通锁就是不分青红皂白都锁起来

mikulch

2017-07-30 16:08:11 +08:00

mysql 的排他锁和共享锁和读锁和写锁可不是一样的东西。和 java 的读写锁也不太一样。共享锁和排他锁针对的是 innoDB 的行级锁。读锁和表锁针对的是 myisam 的表级锁。

不是一个东西无法比较。
另外，mysql 中数据被加上排他锁以后，会阻止该数据被获取独占锁和共享锁。但是允许该数据被读取。
所以数据被读取和获取共享锁不是一个概念。共享锁排他锁也不是读写分离的思想。只是一种并发访问安全性的解决方案而已。

RLib

2017-07-30 16:44:45 +08:00

@mikulch 既然题主说的站在高层看待问题，又为何要扯回具体锁上去。简单来看，一切锁不过是为了保证读和写的安全，为了保证性能，'读'和'写'这两个基本操作的锁肯定是要分开的，那么说共享锁、排他锁(独占锁)有读写分离的思想也无可厚非。另外，我对 mysql 了解不深，但是对你说的“ mysql 中数据被加上排他锁以后...但是允许该数据被读取”存在怀疑，你这里的所谓允许读取，大概是因为 select 时不会去尝试获取和检查锁，所以锁对它根本不起作用，不妨换个角度想，如果那样的话这里读取的安全该由什么保证呢？

ihuotui

2017-07-30 17:58:38 +08:00 via iPhone

@mikulch 在说 mysql 我是指 innodb 引擎，在可重复读事务条件下，事务 a 对某行用了独占锁，其他事务（对同样一行，共享锁和排他锁）都会被阻塞，跟 java 的读写锁差不多就是写的时候变为串行，读并行。

mikulch

2017-07-31 00:29:00 +08:00

@ihuotui
@RLib

要保证读取安全的话其实有很多方式，如果用锁的话自然用起来都差不多。要保证读写安全的话其实除了使用锁使用 COW 类也是可以的。我个人感觉 COW 算是比较彻底的读写分离的思想。读写锁的话我觉得用读写分离来形容实际上不够纯粹。
另外，锁这个东西如果再深入到汇编的话也有相应的 cpu 指令。其实我不太同意两位所说的高层的思想比较相通。其实恰恰是微观的东西都是相通的。就跟现在的所谓一大堆分布式理论一样，都是从微观计算机到宏观分布式的一种延伸。

ihuotui

2017-07-31 01:14:35 +08:00 via iPhone

@mikulch 分布式锁和 java 多线程锁在表现一样（ zk 表现就是多个竞争一个成功，跟 java 锁一样），但是算法理论上实现有区别。还是宏观一样实现不同。