Lock

distributed lock 分布式锁 分布式是一种分布式协调技术，控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。 分布式锁是由于单机锁无法满足分布式系统锁，在多进程/分布式环境下，需要分布式锁来控制共享内容，保证线程的安全。 为何需要分布式锁 Martin Kleppmann 是英国剑桥大学的分布式系统的研究员，之前和 Redis 之父 Antirez 进行过关于 RedLock (红锁，后续有讲到) 是否安全的激烈讨论。 Martin 认为一般我们使用分布式锁有两个场景: 效率: 使用分布式锁可以避免不同节点重复相同的工作，这些工作会浪费资源。比如用户付了钱之后有可能不同节点会发出多封短信。 正确性: 加分布式锁同样可以避免破坏正确性的发生，如果两个节点在同一条数据上面操作， 比如多个节点机器对同一个订单操作不同的流程有可能会导致该笔订单最后状态出现错误，造成损失。 分布式锁的一些特点 当我们确定了在不同节点上需要分布式锁，那么我们需要了解分布式锁到底应该有哪些特点？ 分布式锁的特点如下: 互斥性: 和本地锁一样互斥性是锁最基本的特性, 任意时刻，只有一个客户端能持有锁。 可重入性: 同一个节点上的同一个线程如果获取了锁之后那么也可以再次获取这个锁。 超时释放: 锁失效机制, 防止死锁。正常情况下，请求获取锁之后，处理任务，处理完成之后释放锁。 但是如果在处理任务发生服务异常，或者网络异常时，导致锁无法释放。其他请求都无法获取锁，变成死锁。 为了防止锁变成死锁，需要设置锁的超时时间。过了超时时间后，锁自动释放，其他请求能正常获取锁。 自动续期: 锁设置了超时机制后，如果持有锁的节点处理任务的时候过长超过了超时时间，就会发生线程未处理完任务锁就被释放了， 其他线程就能获取到该锁，导致多个节点同时访问共享资源。对此，就需要延长超时时间。 开启一个监听线程，定时监听任务，监听任务线程还存活就延长超时时间。当任务完成、或者任务发生异常就不继续延长超时时间。 高可用, 高性能: 加锁和解锁需要高效，同时也需要保证高可用防止分布式锁失效，可以增加降级。 安全性: 锁只能被持有锁的客户端释放, 不能被其它客户端释放. 支持阻塞和非阻塞: 和 ReentrantLock 一样支持 lock 和 trylock 以及 tryLock(long timeOut)。即没有获取到锁将直接返回获取锁失败 支持公平锁和非公平锁(可选): 公平锁的意思是按照请求加锁的顺序获得锁，非公平锁就相反是无序的。这个一般来说实现的比较少。 分布式锁一般有三种实现方式: 数据库乐观锁 基于 Redis 的分布式锁 基于 ZooKeeper 的分布式锁 可靠性 首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件: 互斥性。在任意时刻，只有一个客户端能持有锁。 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。 具有容错性。只要大部分的 Redis 节点正常运行，客户端就可以加锁和解锁。 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。 Redis 实现分布式锁 Redis 实现分布式锁，性能会比关系式数据库高一些. ...

golang lock, sync.RWMutex, sync.Mutex, 锁 在 Go 语言并发编程中，倡导使用通信共享内存，不要使用共享内存通信，而这个通信的媒介就是 Channel, Channel 是线程安全的，不需要考虑数据冲突问题，面对并发问题，我们始终应该优先考虑使用Channel，它是 first class 级别的，但是纵使有主角光环加持，Channel也不是万能的，它也需要配角，这也是共享内存存在的价值，其他语言中主流的并发编程都是通过共享内存实现的，共享内存必然涉及并发过程中的共享数据冲突问题，而为了解决数据冲突问题，Go 语言沿袭了传统的并发编程解决方案 - 锁机制，这些锁都位于 sync 包中。 golang 中 sync 包提供了两种锁 Mutex (互斥锁) 和 RWMutex (读写锁), 其中 RWMutex 是基于 Mutex 实现的, 只读锁的实现使用类似引用计数器(Reference Counting)的功能． Mutex: 互斥锁 RWMutex: 读写锁 锁的作用都是为了解决并发情况下共享数据的原子操作和最终一致性问题 Mutex, 互斥锁 type Mutex struct { // contains filtered or unexported fields } func (m *Mutex) Lock() func (m *Mutex) Unlock() sync.Mutex 用于多个 goroutine 对共享资源的互斥访问。使用要点如下： Lock() 加锁，Unlock() 解锁； 对未解锁的 Mutex 使用 Lock() 会阻塞； 对未上锁的 Mutex 使用 Unlock() 会导致 panic 异常。 加锁之后未解锁, 再次加锁会导致死锁 使用 Lock() 加锁后, 便不能再次对其进行加锁, 直到用 Unlock() 解锁对其解锁后, 才能再次加锁. 适用于读写不确定场景, 即读写次数没有明显的区别, 并且只允许只有一个读或者写的场景, 所以该锁也叫做全局锁． ...

Linux中的各种锁, 自旋锁/spin lock, 排队自旋锁、MCS锁、CLH锁 Linux中的各种锁 互斥锁 文件锁 读写锁 Linux作为典型的多用户、多任务、抢占式内核调度的操作系统,为了提高并行处理能力,无论在内核层面还是在用户层面都需要特殊的机制来确保任务的正确性和系统的稳定运行,就如同一个国家需要各种法律条款来约束每个公民的行为,才能有条不紊地运转。 在内核层面涉及到各种软硬件中断、进线程睡眠、抢占式内核调度、多处理器SMP架构等,因此内核在完成自己工作的时候一直在处理这些资源抢占的冲突问题。 在用户层面的进程,虽然Linux作为虚地址模式操作系统,为每个进程开辟了独立的虚拟地址空间,伪独占式拥有资源,但是仍然存在很多场景不得不产生多个进程共享资源的问题,来完成进程间的通信,但是在Go语言中进程间的通信使用消息来完成,处理地更优雅一些。 在线程层面,线程作为进程的一部分,进程内的多个线程只拥有自己的独立堆栈等少量结构,大部分的资源还是过线程共享,因此多线程的资源占用冲突比进程更加明显,所以多线程编程的线程安全问题是个重难点。综上可知,无论在kernel还是user space都必须有一些机制来确保对于资源共享问题的解决,然后这个机制就是接下来要说的: 同步和互斥。 同步和互斥机制 基本概念 同步和互斥的概念有时候很容易混淆,可以简单地认为同步是更加宏观角度的一种说法,互斥是冲突解决的细节方法。所谓同步就是调度者让任务按照约定的合理的顺序进行,但是当任务之间出现资源竞争,也就是竞态冲突时,使用互斥的规则强制约束允许数量的任务占用资源,从而解决各个竞争状态,实现任务的合理运行。 同步和互斥密不可分,有资料说互斥是一种特殊的同步,对此我不太理解,不过实际中想明白细节就行,文字游戏没有意义。 简单来说: 同步与互斥机制是用于控制多个任务对某些特定资源的访问策略 同步是控制多个任务按照一定的规则或顺序访问某些共享资源 互斥是控制某些共享资源在任意时刻只能允许规定数量的任务访问 角色分类 整个协调流程涉及的角色本质上只有三类: 不可独占的共享资源 多个使用者 调度者 调度者需要为多个运行任务制定访问使用规则来实现稳定运行,这个调度者可以是内核、可以是应用程序,具体场景具体分析。 重要术语 要很好地理解同步和互斥,就必须得搞清楚几个重要术语: 竞争冒险(race hazard)或竞态条件(race condition) 最早听说这个术语是在模电数电的课程上,门电路出现竞态条件造成错误的结果,在计算机里面就是多个使用者同时操作共享的变量造成结果的不确定。 临界区 临界区域critical section是指多使用者可能同时共同操作的那部分代码,比如自加自减操作,多个线程处理时就需要对自加自减进行保护,这段代码就是临界区域。 Linux中常用的锁 在说锁之前还需要知道几个东西:信号量和条件变量。这两个东西和锁有一定的联系和区别,在不同的场合单独使用或者配合实现来说实现安全的并发,至于网上很多说互斥锁是一种信号量的特例,对于这种特例理解不了也罢。信号量和互斥锁的场景不一样,信号量主要是资源数量的管理(池化),实际用的频率远不如互斥锁,文字游戏着实无趣,实用主义至上,掌握高频工具的特点正确使用即可,大可不必过于学术派。在使用锁时需要明确几个问题: 锁的所有权问题 谁加锁 谁解锁 解铃还须系铃人 锁的作用就是对临界区资源的读写操作的安全限制 锁是否可以被多个使用者占用(互不影响的使用者对资源的占用) 占用资源的加锁者的释放问题 (锁持有的超时问题) 等待资源的待加锁者的等待问题(如何通知到其他等着资源的使用者) 多个临界区资源锁的循环问题(死锁场景) 带着问题明确想要达到的目的,我们同样可以根据自己的需求设计锁,Linux现有的锁如果从上面几个问题的角度去理解,就非常容易了。 自旋锁 spinlock 自旋锁的主要特征是使用者在想要获得临界区执行权限时,如果临界区已经被加锁,那么自旋锁并不会阻塞睡眠,等待系统来主动唤醒,而是原地忙轮询资源是否被释放加锁,自旋就是自我旋转,这个名字还是很形象的。自旋锁有它的优点就是避免了系统的唤醒,自己来执行轮询,如果在临界区的资源代码非常短且是原子的,那么使用起来是非常方便的,避免了各种上下文切换,开销非常小,因此在内核的一些数据结构中自旋锁被广泛的使用。 互斥锁 mutex 使用者使用互斥锁时在访问共享资源之前对进行加锁操作,在访问完成之后进行解锁操作,谁加锁谁释放,其他使用者没有释放权限。 加锁后,任何其他试图再次加锁的线程会被阻塞,直到当前进程解锁。 区别于自旋锁,互斥锁无法获取锁时将阻塞睡眠,需要系统来唤醒,可以看出来自旋锁自己原地旋转来确定锁被释放了,互斥锁由系统来唤醒,但是现实并不是那么美好的,因为很多业务逻辑系统是不知道的,仍然需要业务线程执行while来轮询是否可以重新加锁。考虑这种情况: 解锁时有多个线程阻塞,那么所有该锁上的线程都被变成就绪状态, 第一个变为就绪状态的线程又执行加锁操作,那么其他的线程又会进入等待,对其他线程而言就是虚假唤醒。 在这种方式下,只有一个线程能够访问被互斥锁保护的资源。 读写锁, 共享互斥锁, rwlock 读写锁也叫共享互斥锁: 读模式共享和写模式互斥,本质上这种非常合理,因为在数据没有被写的前提下,多个使用者读取时完全不需要加锁的。读写锁有读加锁状态、写加锁状态和不加锁状态三种状态,当读写锁在写加锁模式下,任何试图对这个锁进行加锁的线程都会被阻塞,直到写进程对其解锁。 读优先的读写锁: 读写锁 rwlock 默认的也是读优先,也就是:当读写锁在读加锁模式先,任何线程都可以对其进行读加锁操作,但是所有试图进行写加锁操作的线程都会被阻塞,直到所有的读线程都解锁,因此读写锁很适合读次数远远大于写的情况。这种情况需要考虑写饥饿问题,也就是大量的读一直轮不到写,因此需要设置公平的读写策略。在一次面试中曾经问到实现一个写优先级的读写锁,感兴趣的可以想想如何实现。 ...

ReentrantReadWriteLock 一、ReentrantReadWriteLock与ReentrantLock 说到ReentrantReadWriteLock,首先要做的是与ReentrantLock划清界限。它和后者都是单独的实现,彼此之间没有继承或实现的关系。 ReentrantLock 实现了标准的互斥操作,也就是一次只能有一个线程持有锁,也即所谓独占锁的概念。显然这个特点在一定程度上面减低了吞吐量,实际上独占锁是一种保守的锁策略,在这种情况下任何"读/读",“写/读”,“写/写"操作都不能同时发生。但是同样需要强调的一个概念是,锁是有一定的开销的,当并发比较大的时候,锁的开销就比较可观了。所以如果可能的话就尽量少用锁,非要用锁的话就尝试看能否改造为读写锁。 ReadWriteLock 描述的是: 一个资源能够被多个读线程访问,或者被一个写线程访问,但是不能同时存在读写线程。也就是说读写锁使用的场合是一个共享资源被大量读取操作,而只有少量的写操作 (修改数据) 。清单0描述了ReadWriteLock的API。 // 清单0 ReadWriteLock 接口 public interface ReadWriteLock { Lock readLock(); Lock writeLock(); } 清单0描述的ReadWriteLock结构,这里需要说明的是ReadWriteLock并不是Lock的子接口,只不过ReadWriteLock借助Lock来实现读写两个视角。在ReadWriteLock中每次读取共享数据就需要读取锁,当需要修改共享数据时就需要写入锁。看起来好像是两个锁,但其实不尽然,下文会指出。 二、ReentrantReadWriteLock的特性 ReentrantReadWriteLock有以下几个特性: 公平性 非公平锁 (默认) 这个和独占锁的非公平性一样,由于读线程之间没有锁竞争,所以读操作没有公平性和非公平性,写操作时,由于写操作可能立即获取到锁,所以会推迟一个或多个读操作或者写操作。因此非公平锁的吞吐量要高于公平锁。 公平锁利用AQS的CLH队列,释放当前保持的锁 (读锁或者写锁) 时,优先为等待时间最长的那个写线程分配写入锁,当前前提是写线程的等待时间要比所有读线程的等待时间要长。同样一个线程持有写入锁或者有一个写线程已经在等待了,那么试图获取公平锁的 (非重入) 所有线程 (包括读写线程) 都将被阻塞,直到最先的写线程释放锁。如果读线程的等待时间比写线程的等待时间还有长,那么一旦上一个写线程释放锁,这一组读线程将获取锁。 重入性 读写锁允许读线程和写线程按照请求锁的顺序重新获取读取锁或者写入锁。当然了只有写线程释放了锁,读线程才能获取重入锁。 写线程获取写入锁后可以再次获取读取锁,但是读线程获取读取锁后却不能获取写入锁。 另外读写锁最多支持65535个递归写入锁和65535个递归读取锁。 锁降级 写线程获取写入锁后可以获取读取锁,然后释放写入锁,这样就从写入锁变成了读取锁,从而实现锁降级的特性。 锁升级 读取锁是不能直接升级为写入锁的。因为获取一个写入锁需要释放所有读取锁,所以如果有两个读取锁视图获取写入锁而都不释放读取锁时就会发生死锁。 锁获取中断 读取锁和写入锁都支持获取锁期间被中断。这个和独占锁一致。 条件变量 写入锁提供了条件变量(Condition)的支持,这个和独占锁一致,但是读取锁却不允许获取条件变量,将得到一个UnsupportedOperationException异常。 重入数 读取锁和写入锁的数量最大分别只能是65535 (包括重入数) 。 三、ReentrantReadWriteLock的内部实现 3.1 读写锁是独占锁的两个不同视图 ReentrantReadWriteLock里面的锁主体就是一个Sync,也就是上面提到的FairSync或者NonfairSync,所以说实际上只有一个锁,只是在获取读取锁和写入锁的方式上不一样,所以前面才有读写锁是独占锁的两个不同视图一说。 ReentrantReadWriteLock里面有两个类: ReadLock/WriteLock,这两个类都是Lock的实现。 // 清单1 ReadLock 片段 public static class ReadLock implements Lock, java.io.Serializable { private final Sync sync; protected ReadLock(ReentrantReadWriteLock lock) { sync = lock.sync; } public void lock() { sync.acquireShared(1); } public void lockInterruptibly() throws InterruptedException { sync.acquireSharedInterruptibly(1); } public boolean tryLock() { return sync.tryReadLock(); } public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException { return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout)); } public void unlock() { sync.releaseShared(1); } public Condition newCondition() { throw new UnsupportedOperationException(); } } //清单2 WriteLock 片段 public static class WriteLock implements Lock, java.io.Serializable { private final Sync sync; protected WriteLock(ReentrantReadWriteLock lock) { sync = lock.sync; } public void lock() { sync.acquire(1); } public void lockInterruptibly() throws InterruptedException { sync.acquireInterruptibly(1); } public boolean tryLock( ) { return sync.tryWriteLock(); } public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException { return sync.tryAcquireNanos(1, unit.toNanos(timeout)); } public void unlock() { sync.release(1); } public Condition newCondition() { return sync.newCondition(); } public boolean isHeldByCurrentThread() { return sync.isHeldExclusively(); } public int getHoldCount() { return sync.getWriteHoldCount(); } } 清单1描述的是读锁的实现,清单2描述的是写锁的实现。显然WriteLock就是一个独占锁,这和ReentrantLock里面的实现几乎相同,都是使用了AQS的acquire/release操作。当然了在内部处理方式上与ReentrantLock还是有一点不同的。对比清单1和清单2可以看到,ReadLock获取的是共享锁,WriteLock获取的是独占锁。 ...

悲观锁和乐观锁 为什么需要锁 (并发控制) ？ 在多用户环境中,在同一时间可能会有多个用户更新相同的记录,这会产生冲突。这就是著名的并发性问题。 典型的冲突有: 丢失更新: 一个事务的更新覆盖了其它事务的更新结果,就是所谓的更新丢失。例如: 用户A把值从 6 改为 2, 用户B把值从 2 改为 6, 则用户 A 丢失了他的更新。 脏读: 当一个事务读取其它完成一半事务的记录时, 就会发生脏读取。例如: 用户 A, B 看到的值都是 6, 用户 B 把值改为 2, 用户 A 读到的值仍为 6。 为了解决这些并发带来的问题。 我们需要引入并发控制机制。 并发控制机制 最常用的处理多用户并发访问的方法是加锁。当一个用户锁住数据库中的某个对象时,其他用户就不能再访问该对象。加锁对并发访问的影响体现在锁的粒度上。比如,放在一个表上的锁限制对整个表的并发访问；放在数据页上的锁限制了对整个数据页的访问；放在行上的锁只限制对该行的并发访问。可见行锁粒度最小,并发访问最好,页锁粒度最大,表锁介于2者之间。 悲观锁 悲观锁在操作数据时比较悲观,认为别人会同时修改数据。因此操作数据时直接把数据锁住,直到操作完成后才会释放锁；上锁期间其他人不能修改数据。 假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作。悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长,这样可能会长时间的限制其他用户的访问,也就是说悲观锁的并发访问性不好。 乐观锁 乐观锁在操作数据时非常乐观,认为别人不会同时修改数据。因此乐观锁不会上锁,只是在执行更新的时候判断一下在此期间别人是否修改了数据: 如果别人修改了数据则放弃操作,否则执行操作。 假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性。乐观锁不能解决脏读的问题。乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的,因此乐观锁直到你准备提交所作的更改时才将对象锁住,当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短,乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象,那么当他完成了自己的更改进行提交时,数据库就会发现该对象已经变化了,这样,第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中,会增加并发用户读取对象的次数。 从数据库厂商的角度看,使用乐观的页锁是比较好的,尤其在影响很多行的批量操作中可以放比较少的锁,从而降低对资源的需求提高数据库的性能。再考虑聚集索引。在数据库中记录是按照聚集索引的物理顺序存放的。如果使用页锁,当两个用户同时访问更改位于同一数据页上的相邻两行时,其中一个用户必须等待另一个用户释放锁,这会明显地降低系统的性能。interbase和大多数关系数据库一样,采用的是乐观锁,而且读锁是共享的,写锁是排他的。可以在一个读锁上再放置读锁,但不能再放置写锁；你不能在写锁上再放置任何锁。锁是目前解决多用户并发访问的有效手段。 乐观锁应用 使用自增长的整数表示数据版本号。更新时检查版本号是否一致,比如数据库中数据版本为6,更新提交时version=6+1,使用该version值(=7)与数据库version+1(=7)作比较,如果相等,则可以更新,如果不等则有可能其他程序已更新该记录,所以返回错误。 使用时间戳来实现. 注: 对于以上两种方式,Hibernate自带实现方式: 在使用乐观锁的字段前加 annotation: @Version, Hibernate在更新时自动校验该字段。 java中的乐观锁基本都是通过CAS操作实现的 悲观锁应用 结论 在实际生产环境里边,如果并发量不大且不允许脏读,可以使用悲观锁解决并发问题；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法. 参考文档 [1]Concurrent Control http://en.wikipedia.org/wiki/Concurrency_control [2] Oracle的悲观锁和乐观锁http://space.itpub.net/12158104/viewspace-374745 [3] timestamp应用——乐观锁和悲观锁【转】http://hi.baidu.com/piaokes/blog/item/9b0c6854e4909050564e00b3.html 事务隔离 https://www.cnblogs.com/kismetv/p/10787228.html http://www.cnblogs.com/Bob-FD/p/3352216.html

synchronized 多线程 在现代计算机中往往存在多个CPU核心，而1个CPU能同时运行一个线程，为了充分利用CPU多核心，提高CPU的效率，多线程就应时而生了。 那么多线程就一定比单线程快吗? 答案是不一定，因为多线程存在单线程没有的问题 上下文切换 线程执行过程中发生系统调用或者线程调度时都会发生上下文切换 线程从运行状态切换到阻塞状态或者等待状态的时候需要将线程的运行状态保存，线程从阻塞状态或者等待状态切换到运行状态的时候需要加载线程上次运行的状态。线程的运行状态从保存到再加载就是一次上下文切换，而上下文切换的开销是非常大的，而我们知道CPU给每个线程分配的时间片很短，通常是几十毫秒(ms)，那么线程的切换就会很频繁。 死锁 死锁的一般场景是，线程A和线程B都在互相等待对方释放锁，死锁会造成系统不可用。 资源限制的挑战 资源限制指计算机硬件资源或软件资源限制了多线程的运行速度，例如某个资源的下载速度是1Mb/s，资源的服务器带宽只有2Mb/s，那么开10个线程下载资源并不会将下载速度提升到10Mb/s。 既然多线程存在这些问题，那么我们在开发的过程中有必要使用多线程吗？我们知道任何技术都有它存在的理由，总而言之就是多线程利大于弊，只要我们合理使用多线程就能达到事半功倍的效果。 多线程的意思就是多个线程同时工作，那么多线程之间如何协同合作，这也就是我们需要解决的线程通信、线程同步问题 线程通信 线程通信指线程之间以何种机制来交换消息，线程之间的通信机制有两种: 共享内存和消息传递。共享内存即线程通过对共享变量的读写而达到隐式通信，消息传递即线程通过发送消息给对方显示的进行通信。 线程同步 线程同步指不同线程对同一个资源进行操作时候线程应该以什么顺序去操作，线程同步依赖于线程通信，以共享内存方式进行线程通信的线程同步是显式的，以消息传递方式进行线程通信的线程同步是隐式的。 synchronized synchronized 的锁机制的主要优势是Java语言内置的锁机制，因此，JVM可以自由的优化而不影响已存在的代码。 synchronized 是 Java 的关键字，可用于同步实例方法、类方法(静态方法)和代码块 同步实例方法: 当 synchronized 修饰实例方法 (函数修饰符）的时候，同步的范围是当前实例的实例方法。 同步类方法(静态方法): 当 synchronized 修饰类方法的时候，同步的范围是当前类的方法。用synchronized修饰方法名时，编译后会在方法名上生成一个ACC_SYNCHRONIZED标识来实现同步 同步代码块: 当 synchronized 修饰代码块的时候，同步的范围是()中的对象。当使用synchronized修饰代码块时，编译后会在代码块的前后生成monitorenter和monitorexit字节码来实现同步。 synchronized 是非公平锁 synchronized 关键字经过编译之后，会在同步块的前后分别形成 monitorenter 和 monitorexit 这两个字节码指令，这两个字节码需要关联到一个监视对象，当线程执行 monitorenter 指令时，需要首先获得获得监视对象的锁，这里监视对象锁就是进入同步块的凭证，只有获得了凭证才可以进入同步块，当线程离开同步块时，会执行 monitorexit 指令，释放对象锁。 synchronized 关键字，代表这个方法加锁,相当于不管哪一个线程 (例如线程A) ，运行到这个方法时, 都要检查有没有其它线程B (或者C、 D等) 正在用这个方法，有的话要等正在使用 synchronized 方法的线程B (或者C 、D) 运行完这个方法后再运行此线程 A,没有的话,直接运行。 markword markword 数据的长度在32位和64位的虚拟机 (未开启压缩指针) 中分别为32bit和64bit，它的最后2bit是锁状态标志位，用来标记当前对象的状态，对象的所处的状态，决定了markword存储的内容 ...

Synchronized 和 java.util.concurrent.locks.Lock 的区别 主要相同点: Lock 能完成 Synchronized 所实现的所有功能。 主要不同点: Lock 有比 Synchronized 更精确的线程语义和更好的性能。Synchronized 会自动释放锁，但是 Lock 一定要求程序员手工释放，并且必须在 finally 从句中释放。 synchronized 修饰方法 synchronized 修饰方法时 表示同一个对象在不同的线程中表现为同步队列 如果实例化不同的对象 那么synchronized就不会出现同步效果了。 对象的锁 所有对象都自动含有单一的锁。 JVM负责跟踪对象被加锁的次数。如果一个对象被解锁，其计数变为0。在任务 (线程) 第一次给对象加锁的时候，计数变为1。每当这个相同的任务 (线程) 在此对象上获得锁时，计数会递增。 只有首先获得锁的任务 (线程) 才能继续获取该对象上的多个锁。 每当任务离开一个 synchronized 方法，计数递减，当计数为0的时候，锁被完全释放，此时别的任务就可以使用此资源。 synchronized同步块 2.1同步到单一对象锁 当使用同步块时，如果方法下的同步块都同步到一个对象上的锁，则所有的任务 (线程) 只能互斥的进入这些同步块。 Resource1.java演示了三个线程 (包括main线程) 试图进入某个类的三个不同的方法的同步块中，虽然这些同步块处在不同的方法中，但由于是同步到同一个对象 (当前对象 synchronized (this)) ，所以对它们的方法依然是互斥的。 比如 Class Test{ public static User user=null; Public synchronized void add(User u){ user=u; Dao.save(user) } } //如果在线程1中 Test test=new Test(); User u=new User(); u.setUserName("liaomin"); u.setUserPassword("liaomin"); Test.add(u); //如果在线程2中 Test tes1t=new Test(); User u1=new User(); u1.setUserName("huqun"); u1.setUserPassword("huqun"); Tes1t.add(u1); 那么 现在线程1 和线程2同时启动 如果对象new的不是同一个Test ...

ReentrantLock，互斥锁，重入锁 在并发编程中，多线程同时并发访问的资源叫做临界资源，当多个线程同时访问对象并要求操作相同资源时，分割了原子操作就有可能出现数据的不一致或数据不完整的情况，为避免这种情况的发生，我们会采取同步机制，以确保在某一时刻，方法内只允许有一个线程。 synchronized 采用 synchronized 修饰符实现的同步机制叫做互斥锁机制，它所获得的锁叫做互斥锁。每个对象都有一个 monitor (锁标记)，当线程拥有这个锁标记时才能访问这个资源，没有锁标记便进入锁池。任何一个对象系统都会为其创建一个互斥锁，这个锁是为了分配给线程的，防止打断原子操作。每个对象的锁只能分配给一个线程，因此叫做互斥锁。 这里就使用同步机制获取互斥锁的情况，进行几点说明: 如果同一个方法内同时有两个或更多线程，则每个线程有自己的局部变量拷贝。 类的每个实例都有自己的对象级别锁。当一个线程访问实例对象中的 synchronized 同步代码块或同步方法时，该线程便获取了该实例的对象级别锁，其他线程这时如果要访问 synchronized 同步代码块或同步方法，便需要阻塞等待，直到前面的线程从同步代码块或方法中退出，释放掉了该对象级别锁。 访问同一个类的不同实例对象中的同步代码块，不存在阻塞等待获取对象锁的问题，因为它们获取的是各自实例的对象级别锁，相互之间没有影响。 持有一个对象级别锁不会阻止该线程被交换出来，也不会阻塞其他线程访问同一示例对象中的非synchronized代码。当一个线程A持有一个对象级别锁 (即进入了 synchronized 修饰的代码块或方法中) 时，线程也有可能被交换出去，此时线程B有可能获取执行该对象中代码的时间，但它只能执行非同步代码 (没有用synchronized修饰) ，当执行到同步代码时，便会被阻塞，此时可能线程规划器又让A线程运行，A线程继续持有对象级别锁，当A线程退出同步代码时 (即释放了对象级别锁) ，如果B线程此时再运行，便会获得该对象级别锁，从而执行synchronized中的代码。 持有对象级别锁的线程会让其他线程阻塞在所有的 synchronized 代码外。例如，在一个类中有三个synchronized方法 a，b，c，当线程A正在执行一个实例对象M中的方法 a 时，它便获得了该对象级别锁，那么其他的线程在执行同一实例对象 (即对象M) 中的代码时，便会在所有的 synchronized 方法处阻塞，即在方法 a，b，c处都要被阻塞，等线程A释放掉对象级别锁时，其他的线程才可以去执行方法a，b或者c中的代码，从而获得该对象级别锁。 使用 synchronized (obj) 同步语句块，可以获取指定对象上的对象级别锁。obj为对象的引用，如果获取了obj对象上的对象级别锁，在并发访问obj对象时时，便会在其synchronized代码处阻塞等待，直到获取到该obj对象的对象级别锁。当obj为 this 时，便是获取当前对象的对象级别锁。 类级别锁被特定类的所有示例共享，它用于控制对static成员变量以及static方法的并发访问。具体用法与对象级别锁相似。 互斥是实现同步的一种手段，临界区、互斥量和信号量都是主要的互斥实现方式. synchronized 关键字经过编译后，会在同步块的前后分别形成 monitorenter 和 monitorexit 这两个字节码指令。根据虚拟机规范的要求，在执行 monitorenter 指令时，首先要尝试获取对象的锁，如果获得了锁，把锁的计数器加1，相应地，在执行 monitorexit 指令时会将锁计数器减1，当计数器为0时，锁便被释放了。由于synchronized 同步块对同一个线程是可重入的，因此一个线程可以多次获得同一个对象的互斥锁，同样，要释放相应次数的该互斥锁，才能最终释放掉该锁。 synchronized 是非公平锁 (TODO: 需要测试，没重现成功…) https://blog.csdn.net/FU250/article/details/106640613 ReentrantLock ReentrantLock 是一个可重入的互斥锁，又被称为"独占锁"。ReentrantLock 的实现不仅可以替代隐式的 synchronized 关键字，而且能够提供超过关键字本身的多种功能。 而锁的名字也是说明了这个锁具备了重复进入的可能，也就是说能够让当前线程多次的进行对锁的获取操作，这样的最大次数限制是 Integer.MAX_VALUE，约 21 亿次左右。 ...

“futex” futex (fast userspace mutex) 是Linux的一个基础构件，可以用来构建各种更高级别的同步机制，比如锁或者信号量等等，POSIX信号量就是基于futex构建的。大多数时候编写应用程序并不需要直接使用futex，一般用基于它所实现的系统库就够了。 futex的性能非常优异，它是怎样做到的呢？这要从它的设计思想谈起。传统的SystemV IPC(inter process communication)进程间同步机制都是通过内核对象来实现的，以 semaphore 为例，当进程间要同步的时候，必须通过系统调用semop(2)进入内核进行PV操作。系统调用的缺点是开销很大，需要从user mode切换到kernel mode、保存寄存器状态、从user stack切换到kernel stack、等等，通常要消耗上百条指令。事实上，有一部分系统调用是可以避免的，因为现实中很多同步操作进行的时候根本不存在竞争，即某个进程从持有semaphore直至释放semaphore的这段时间内，常常没有其它进程对同一semaphore有需求，在这种情况下，内核的参与本来是不必要的，可是在传统机制下，持有semaphore必须先调用semop(2)进入内核去看看有没有人和它竞争，释放semaphore也必须调用semop(2)进入内核去看看有没有人在等待同一semaphore，这些不必要的系统调用造成了大量的性能损耗。futex就为了解决这个问题而生的，它的办法是: 在无竞争的情况下，futex的操作完全在user space进行，不需要系统调用，仅在发生竞争的时候进入内核去完成相应的处理(wait 或者 wake up)。所以说，futex是一种user mode和kernel mode混合的同步机制，需要两种模式合作才能完成，futex变量必须位于user space，而不是内核对象，futex的代码也分为user mode和kernel mode两部分，无竞争的情况下在user mode，发生竞争时则通过sys_futex系统调用进入kernel mode进行处理，具体来说: futex 变量是位于 user space 的一个整数，支持原子操作。futex 同步操作都是从user space开始的: 当要求持有futex的时候，对futex变量执行”down”操作，即原子递减，如果变量变为0，则意味着没有竞争发生，进程成功持有futex 并继续在user mode运行；如果变量变为负数，则意味着有竞争发生，需要通过sys_fute x系统调用进入内核执行futex_wait操作，让进程进入休眠等待。 当释放futex的时候，对futex变量进行”up”操作，即原子递增，如果变量变成1，则意味着没有竞争发生，进程成功释放futex并继续在user mode执行；否则意味着有竞争，需要通过sys_futex 系统调用进入内核执行 futex_wake 操作，唤醒正在等待的进程。 如果需要在多个进程之间共享futex，那就必须把futex变量放在共享内存中，并确保这些进程都有访问共享内存的权限；如果仅需在线程之间使用futex的话，那么futex变量可以位于进程的私有内存中，比如普通的全局变量即可。 更详细的信息请参阅futex作者的论文: Fuss, Futexes and Furwocks: Fast Userlevel Locking in Linux http://linuxperf.com/?p=23 什么是 Futex Futex,作为linux下的一种快速同步 (互斥) 机制 Futex 是Fast Userspace muTexes的缩写,由Hubertus Franke, Matthew Kirkwood, Ingo Molnar and Rusty Russell共同设计完成。几位都是linux领域的专家,其中可能Ingo Molnar大家更熟悉一些,毕竟是O(1)调度器和CFS的实现者。 ...