AQS (AbstractQueuedSynchronizer
)
他的实现类诸如:
CountDownLatch
、ThreadLocalPool
和ReentrantLock
在这些类中,AQS
都是以内部类的形式存在的
AQS使用了模板方法设计模式
例子:
做蛋糕分为3个步骤,定一个抽象类,重写3个方法,做模型、烘焙和涂抹原料,然后在另外1个方法做蛋糕中,将这3个方法步骤依次放入;
然后具体的实现类继承自上面抽象类,比如做奶油蛋糕有奶油蛋糕的制作流程,做芝士蛋糕有芝士蛋糕的制作流程等等.
如何自己实现一个锁?
重写一个类MyLock
实现Lock
,然后重写Lock
类中的lock
和unLock
方法;然后重写1
个内部类MyAQS
继承自AQS
,然后重写AQS
中的tryAcquire
方法和tryRelease
方法,这两个方法其实就是要更改AQS
中state
的状态:
AQS
中state
的状态改为1
,即为获得锁(CAS
实现,compareAndSetState(1, acquires)
),同时调用setExclusiveOwnerThread(Thread.currentThread)
,设置当前线程获得锁;
AQS
中state
的状态改为改为0
,即为释放锁,同时调用setExclusiveOwnerThread(null)
,当前线程释放锁;
最后在自定义的MyLock
中的lock
和unLock
方法中分别调用MyAQS.tryAcquire
方法和MyAQS.tryRelease
方法,即完成了一个自定义的Lock
类.
AQS基本思想CLH队列锁
双链表实现,链表中每一个结点不停的去自旋(正常情况有次数限制,一般是2
次,然后进入阻塞状态),查看前一个结点是否已经使用完锁并释放,前一个结点释放锁的同时当前结点的myPred
为null
,同时将当前结点的locked
状态改为false
;
了解ReentrantLock的实现
- 锁的可重入
在递归或者是同步方法中包含了同步方法,就可能会出现锁的可重入问题,可以改造我们锁的state状态,如果发现是同一个线程在获取锁,state++;释放锁的时候state--
- 公平锁和非公平锁
公平锁与非公平锁的区别就是这1行代码
hasQueuedPredecessors(),公平锁会检测是否有等待队列,有等待队列则将新插入的线程添加到链表尾部;非公平锁则会与当前链表竞争锁
JMM (Java Memory Model 内存模型)
什么是工作内存和主内存?
主内存有点类似于JVM
中的堆
,而工作内存则类似于JVM
中的栈
.
正常情况定一个变量count
,这个变量count
是放在主内存的,而多个线程在对这个变量进行运算比如加1
,这个操作过程是放在工作内存中完成的,每个工作内存都拥有一个这个主内存变量count
的副本countCopy
,并且每个子线程之间这个变量的副本是相互之间不可见的,当每个线程在运算完成后,会将这个变量副本countCopy
赋值给主内存中的变量count
(这里就是volatile可见性的作用,让别的子线程从主内存中拿到的这个变量值是最新的,而不是最初没有子线程操作过的那个旧的变量值
).
JMM导致的并发安全问题?
count = count + 1;
真的就只有一条语句吗?
可见性
- 不同的线程之间做同一个变量的更改,可能存在可见性问题,不同线程更改变量副本后,主内存中变量的值可能不正确,可以采用加
volitile
(保证可见性
)和锁
(同时保证可见性和原子性
)解决这个问题
- 不同的线程之间做同一个变量的更改,可能存在可见性问题,不同线程更改变量副本后,主内存中变量的值可能不正确,可以采用加
原子性
- 不同线程之间在更改同一个变量时,比如变量累加
i++
这个过程转换成字节码时,存在多行代码,在多行代码在执行的过程中,可能被别的线程打断,从而导致了别的线程处理完成后更改了主内存中变量的值,而被打断的线程继续执行字节码后面的逻辑,而没有从主内存中重新去取变量的值,导致了被打断的线程执行完成后,去更改主内存中变量的值,此时,这个是一个错误的值.
- 不同线程之间在更改同一个变量时,比如变量累加