操作系统os级别, 实现同步的方法
1.互斥量mutex:
具体是这个对象: pthread_mutex_t(互斥锁)
拿不到锁 就休眠
↑用法和java里面差不多
jvm里面重量锁 就是用的这个
2.自旋锁spinLock:
pthread_spin_t
拿不到锁 就自旋(重试)
os空转
使用都是差不多的
3.信号量
为什么用了 mutex 就是重量锁? 怎么重?
因为这里会sleep()
sleep()进入内核态, 因为是系统调用
内核态和用户态, 是看当前的cpu
intel x86 CPU有四种不同的执行级别0-3，linux只使用了其中的0级和3级分别来表示内核态和用户态，
所谓的内核态和用户态其实仅仅是CPU的一个权限而已
用户态切换到内核态的3种方式
a. 系统调用
b. 异常（这个异常不是java当中的异常）
c. 外围设备的中断
其实站在java程序员的角度只需要关注系统调用，因为系统调用可以认为是用户进程主动发起的
内核态就是要访问操作系统的那部分内存, 因为比较危险, cpu级别上升
切换到内核态, 要先保留用户态的线程私有信息, 这也是一种上下文切换(平时遇到的一般是同进程不同线程之间的上下文切换)
上下文切换 这4个都是 需要保留的数据不同:
进程间
内核态 用户态
不同进程的线程
同进程线程 ❤
自旋锁
javaer说的自旋锁, 一般 不是指 操作系统的 spinLock,
而是指各种java代码对自旋的实现 比如
ReentrantLock 里面有实现自旋, 但是没有os自旋, 用的还是 mutex
synchronized 不是自旋锁
synchronized 原本用的是 互斥量(就是重量锁用的), 只有就没有操作系统说的spinLock自旋锁,
但是后来有优化?? jvm代码里面有自旋吗? 没有!
synchronized 字节码是 monitorenter, 这个字节码解析是
↑可以看到 么有偏向就试试轻量级锁
↑可以看到 轻量锁 也没有循环重试(自旋锁实现), 而是 最后不行就膨胀 变成 重量锁
ObjectMonitor* ObjectSynchronizer::inflate
↑重量锁里面 有自旋 但是 是为了等膨胀 不是等锁, 所以不是自旋锁
所以结论:synchronized 从偏向 轻量 到重量 都没自旋 不是自旋锁
1.6以后 自适应自旋锁:
锁的情况预测, 给出合适的自旋时间, 更加智能
坏处:
浪费cpu
可能饿死
