云浮新兴哪有做网站的关键词优化排名要多少钱
文章目录
- 乐观锁和悲观锁
- 重量级锁和轻量级锁
- 挂起等待锁和自旋锁
- 公平锁和非公平锁
- 可重入锁和不可重入锁
- 读写锁
- 相关面试题
锁：非常广义的概念，不是指某个具体的锁，所有的锁都可以往这些策略中套
synchronized：只是市面上五花八门的锁种，其中一种典型的实现，Java 内置的，推荐使用的锁
乐观锁和悲观锁
这两个词不是指某个具体的锁，而是锁的一种“特性”，描述了“一类”
乐观锁：加锁的时候，假设出现冲突的概率不大
- 接下来围绕加锁要做的工作就会更少
悲观锁：加锁的时候，假设出现锁冲突的概率很大 - 接下来围绕加锁要做的工作就会更多
使用 synchronized，初始情况下，是乐观的（预估接下来锁冲突概率不大）
- 同时会在背后偷偷地统计锁冲突了多少次
- 如果发现锁冲突达到一定程度了，就会转变为“悲观的”
乐观锁和悲观锁需要做的事情是不同的 - 乐观做的事情少一点
- 悲观做的事情往往更重量级
站在预测锁冲突的概率是否高
synchronized是自适应的
重量级锁和轻量级锁
效果和悲观乐观是重叠的，只是站在的角度不一样
重量级锁：加锁的开销比较大，要做的工作更多
- 往往悲观的时候，会做的重
轻量级锁：加锁的开销比较小，要做的工作相对更少 - 往往乐观的时候，会做的轻
但也不能认为是 100%等价，因为： - 乐观和悲观是站在“预估所冲突”角度
- 重量轻量是站在“加锁开销“角度
站在加锁的开销角度
synchronized也是自适应的
挂起等待锁和自旋锁
挂起等待锁：属于是悲观锁/重量级锁的一种典型实现
自旋锁：乐观锁/轻量级锁的一种典型实现
比如：
你去追你的女神：
女神女神，我好喜欢你，
你尝试对女神加锁
女神表示：我有男朋友了女神表示她这把锁已经被别的线程给加了
你就可以选择“等待”，等到女神锁被释放，比如：你选择每天仍然会给女神不停地问候“早安，午安…”，这里的行为称为“自旋锁”
- 这里的等待是“忙等”，等待的过程中 CPU 的资源不会释放
- 某天女神和男朋友吵架了，不开心，你就立刻能感知到，机会来了。这样你就可以在女神锁释放的第一时间，立刻抓住机会，能够上位
- 不停地，循环地检测锁是否被释放，一旦锁释放，就能立即有机会能获得锁
你选择把女神拉黑，先不联系了，若干年后你从别人那里听说，女神分手了，你再去联络女神，这种行为就是“挂起等待锁”
- 不联系，就相当于“让出 CPU 资源”CPU 就可以去做别的事了
- 不理女神之后，我们就可以有心思好好学习，好好敲代码，好好找工作了，在过程中做成更多的事情。过了一段时间后，我们通过一些途径听说女神分手了，再伺机而动，但“听说”的时效性很低，这个中间可能有很长的时间跨度。在这个时间跨度里，女神是否由谈了男朋友？分手了多少次？你是不知道的
- 挂机时间更长，但能节省下 CPU 资源去做别的事情
注意：
- 只有在假定锁冲突概率不高的情况下，才能“忙等”。如果好几个线程都在竞争同一个锁，一个线程拿到锁，其他的都在“忙等”，这样总的 CPU 消耗就会非常高
- 而且，由于竞争太激烈，导致有些线程要等待很久才能拿到锁
- 锁冲突很高的概率很高的话就不适合“自旋锁”方案
- 挂起等待锁也就适合“悲观锁”这样的场景了
- 锁竞争非常激烈，预测拿到锁的概率本身就不打，不放吧 CPU 让出来，充分的做其他事情
synchronized“自适应”
- 轻量级锁就是基于自旋的方式实现的（JVM 内部，用户态代码实现）
- 重量级锁就是基于挂起等待的方式实现的（调用操作系统 API，在内核中实现）
纯用户态代码往往执行效率比内核态代码的高一些，总体来说，我们还是认为“自旋”的效率更高的，但是 CPU 开销更大
挂起等待锁的操作虽然 CPU 开销变少了，但整体的等待时间更多
公平锁和非公平锁
日常生活中，说的公平可能有不同的含义
当女神分手了，该轮到谁上位呢？
公平锁： 在计算机中，约定“先来后到”为公平
非公平锁： 系统原生
synchronized 属于非公平锁
- 当
N个线程竞争同一个锁，其中一个线程拿到锁了，后续该线程释放锁之后，剩下的N-1个线程，就要重新竞争锁，谁能拿到锁，就不一定了 - 当然，也不能保证这些线程竞争中获取的概率一定是数学上的严格均等
本身操作系统内核里针对锁的处理就是如此，synchronized在系统内核的基础上，没有做啥额外的操作
如需要使用公平锁，就需要做额外的工作
- 比如引入队列，记录每个线程加锁的顺序
可重入锁和不可重入锁
死锁问题：如果一个线程，针对同一把锁，连续加锁两次，就可能出现死锁，如果把锁设为“可重入”就可以避免死锁了
可重入：是专门的计算机术语，不要写作“可重复”这样的词
可重入锁
- 会记录当前是哪个线程持有了这把锁
- 在加锁的时候判定，当前申请锁的线程，是否就是锁的持有者
- 计数器，记录加锁的次数，从而确定何时真正释放锁
- 遇到一个
{加一次锁，计数器加一 - 遇到一个
}解锁一次，计数器减一 - 等到计数器为零，真正释放锁
- 遇到一个
读写锁
synchronized 并非是读写锁
所谓的读写锁，把“加锁操作”分为两种情况
- 读加锁
- 写加锁
如果多个线程同时读这个变量，没有线程安全问题，但是 - 一个线程读/一个线程写
- 两个线程都写
就会产生问题
在实际开发中，在大部分场景下，读操作的频次，本身就比写操作的频次高。所以就让读操作不产生锁冲突，这样就只有少数写操作会产生冲突，这样效率就高了
读写锁提供了两种加锁的 API，系统内置的锁，Java 标准库中的读写锁类为：ReentrantReadWriteLock
- 加读锁
ReentrantReadWriteLock的内部类ReentrantReadWriteLock.ReadLock表示加读锁，这个对象提供了lock/unlock⽅法进⾏加锁解锁
- 加写锁
ReentrantReadWriteLock的内部类ReentrantReadWriteLock.WriteLock表示加写锁，这个对象也提供了lock/unlock⽅法进⾏加锁解锁
解锁的 API 是一样的，就需要把 unlock 放到 finally 中，确保能够执行到
- 如果两个线程都是按照读方式加锁，此时不会产生锁冲突；
- 如果两个线程都是家写锁，此时会产生锁冲突
- 如果一个线程读锁，一个线程写锁，也会产生冲突
相关面试题
