自旋鎖
package concurrency.lock;
import java.util.concurrent.atomic.AtomicReference;
/**
* 自旋鎖（spinlock）：是指當一個線程在獲取鎖的時候，如果鎖已經被其它線程獲取，那麼該線程將循環等待，然後不斷的判斷鎖是否能夠被成功獲取，直到獲取到鎖纔會退出循環。
獲取鎖的線程一直處於活躍狀態，但是並沒有執行任何有效的任務，使用這種鎖會造成busy-waiting。
它是爲實現保護共享資源而提出一種鎖機制。其實，自旋鎖與互斥鎖比較類似，它們都是爲了解決對某項資源的互斥使用。無論是互斥鎖，還是自旋鎖，在任何時刻，最多只能有一個保持者，也就說，在任何時刻最多只能有一個執行單元獲得鎖。但是兩者在調度機制上略有不同。對於互斥鎖，如果資源已經被佔用，資源申請者只能進入睡眠狀態。但是自旋鎖不會引起調用者睡眠，如果自旋鎖已經被別的執行單元保持，調用者就一直循環在那裏看是否該自旋鎖的保持者已經釋放了鎖，”自旋”一詞就是因此而得名。
lock（)方法利用的CAS，當第一個線程A獲取鎖的時候，能夠成功獲取到，不會進入while循環，如果此時線程A沒有釋放鎖，另一個線程B又來獲取鎖，此時由於不滿足CAS，所以就會進入while循環，不斷判斷是否滿足CAS，直到A線程調用unlock方法釋放了該鎖。
自旋鎖存在的問題
如果某個線程持有鎖的時間過長，就會導致其它等待獲取鎖的線程進入循環等待，消耗CPU。使用不當會造成CPU使用率極高。
上面Java實現的自旋鎖不是公平的，即無法滿足等待時間最長的線程優先獲取鎖。不公平的鎖就會存在“線程飢餓”問題。
自旋鎖的優點
自旋鎖不會使線程狀態發生切換，一直處於用戶態，即線程一直都是active的；不會使線程進入阻塞狀態，減少了不必要的上下文切換，執行速度快
非自旋鎖在獲取不到鎖的時候會進入阻塞狀態，從而進入內核態，當獲取到鎖的時候需要從內核態恢復，需要線程上下文切換。 （線程被阻塞後便進入內核（Linux）調度狀態，這個會導致系統在用戶態與內核態之間來回切換，嚴重影響鎖的性能）
*/
public class SpinLock {
private AtomicReference<Thread> cas = new AtomicReference<Thread>();
public void lock() {
Thread current = Thread.currentThread();
// 利用CAS
while (!cas.compareAndSet(null, current)) {
// DO nothing
}
}
public void unlock() {
Thread current = Thread.currentThread();
cas.compareAndSet(current, null);
}
}
郵戳鎖
package concurrency.lock;
import java.util.concurrent.locks.StampedLock;
public class StampedLockTest {
private double x, y;//內部定義表示座標點
private final StampedLock s1 = new StampedLock();//定義了StampedLock鎖,
void move(double deltaX, double deltaY) {
long stamp = s1.writeLock();//這裏的含義和distanceFormOrigin方法中 s1.readLock()是類似的
try {
x += deltaX;
y += deltaY;
} finally {
s1.unlockWrite(stamp);//退出臨界區,釋放寫鎖
}
}
double distanceFormOrigin() {//只讀方法
long stamp = s1.tryOptimisticRead(); //試圖嘗試一次樂觀讀 返回一個類似於時間戳的郵戳整數stamp 這個stamp就可以作爲這一個所獲取的憑證
double currentX = x, currentY = y;//讀取x和y的值,這時候我們並不確定x和y是否是一致的
if (!s1.validate(stamp)) {//判斷這個stamp是否在讀過程發生期間被修改過,如果stamp沒有被修改過,責任無這次讀取時有效的,因此就可以直接return了,反之,如果stamp是不可用的,則意味着在讀取的過程中,可能被其他線程改寫了數據,因此,有可能出現髒讀,如果如果出現這種情況,我們可以像CAS操作那樣在一個死循環中一直使用樂觀鎖,知道成功爲止
stamp = s1.readLock();//也可以升級鎖的級別,這裏我們升級樂觀鎖的級別,將樂觀鎖變爲悲觀鎖, 如果當前對象正在被修改,則讀鎖的申請可能導致線程掛起.
try {
currentX = x;
currentY = y;
} finally {
s1.unlockRead(stamp);//退出臨界區,釋放讀鎖
}
}
return Math.sqrt(currentX * currentX + currentY * currentY);
}
public static void main(String[] args) {
new StampedLockTest().distanceFormOrigin();
}
}
可重入自旋鎖
public class ReentrantSpinLock {
private AtomicReference<Thread> cas = new AtomicReference<Thread>();
private int count;
public void lock() {
Thread current = Thread.currentThread();
if (current == cas.get()) { // 如果當前線程已經獲取到了鎖，線程數增加一，然後返回
count++;
return;
}
// 如果沒獲取到鎖，則通過CAS自旋
while (!cas.compareAndSet(null, current)) {
// DO nothing
}
}
public void unlock() {
Thread cur = Thread.currentThread();
if (cur == cas.get()) {
if (count > 0) {// 如果大於0，表示當前線程多次獲取了該鎖，釋放鎖通過count減一來模擬
count--;
} else {// 如果count==0，可以將鎖釋放，這樣就能保證獲取鎖的次數與釋放鎖的次數是一致的了。
cas.compareAndSet(cur, null);
}
}
}
}
TicketLock
package concurrency.lock;
import java.util.concurrent.atomic.AtomicInteger;
/**
* 每當有線程獲取鎖的時候，就給該線程分配一個遞增的id，我們稱之爲排隊號，同時，鎖對應一個服務號，每當有線程釋放鎖，服務號就會遞增，此時如果服務號與某個線程排隊號一致，那麼該線程就獲得鎖，由於排隊號是遞增的，所以就保證了最先請求獲取鎖的線程可以最先獲取到鎖，就實現了公平性。
可以想象成銀行辦理業務排隊，排隊的每一個顧客都代表一個需要請求鎖的線程，而銀行服務窗口表示鎖，每當有窗口服務完成就把自己的服務號加一，此時在排隊的所有顧客中，只有自己的排隊號與服務號一致的纔可以得到服務。
上面的實現方式是，線程獲取鎖之後，將它的排隊號返回，等該線程釋放鎖的時候，需要將該排隊號傳入。但這樣是有風險的，因爲這個排隊號是可以被修改的，一旦排隊號被不小心修改了，那麼鎖將不能被正確釋放
* <p>Company: 壽險總部核心系統開發部後端批處理系統開發團隊再保精算開發組</p>
* 多處理器系統上，每個進程/線程佔用的處理器都在讀寫同一個變量serviceNum ，每次讀寫操作都必須在多個處理器緩存之間進行緩存同步，這會導致繁重的系統總線和內存的流量，大大降低系統整體的性能。
*/
public class TicketLock {
/**
* 服務號
*/
private AtomicInteger serviceNum = new AtomicInteger();
/**
* 排隊號
*/
private AtomicInteger ticketNum = new AtomicInteger();
/**
* 新增一個ThreadLocal，用於存儲每個線程的排隊號
*/
private ThreadLocal<Integer> ticketNumHolder = new ThreadLocal<Integer>();
public void lock() {
int currentTicketNum = ticketNum.incrementAndGet();
// 獲取鎖的時候，將當前線程的排隊號保存起來
ticketNumHolder.set(currentTicketNum);
while (currentTicketNum != serviceNum.get()) {
// Do nothing
}
}
public void unlock() {
// 釋放鎖，從ThreadLocal中獲取當前線程的排隊號
Integer currentTickNum = ticketNumHolder.get();
serviceNum.compareAndSet(currentTickNum, currentTickNum + 1);
}
}
MCSLock
都是基於鏈表，不同的是CLHLock是基於隱式鏈表，沒有真正的後續節點屬性，MCSLock是顯示鏈表，有一個指向後續節點的屬性。
將獲取鎖的線程狀態藉助節點(node)保存,每個線程都有一份獨立的節點，這樣就解決了TicketLock多處理器緩存同步的問題
自旋鎖：線程獲取鎖的時候，如果鎖被其他線程持有，則當前線程將循環等待，直到獲取到鎖。
自旋鎖等待期間，線程的狀態不會改變，線程一直是用戶態並且是活動的(active)。
自旋鎖如果持有鎖的時間太長，則會導致其它等待獲取鎖的線程耗盡CPU。
自旋鎖本身無法保證公平性，同時也無法保證可重入性。
基於自旋鎖，可以實現具備公平性和可重入性質的鎖。
TicketLock:採用類似銀行排號叫好的方式實現自旋鎖的公平性，但是由於不停的讀取serviceNum，每次讀寫操作都必須在多個處理器緩存之間進行緩存同步，這會導致繁重的系統總線和內存的流量，大大降低系統整體的性能。
CLHLock和MCSLock通過鏈表的方式避免了減少了處理器緩存同步，極大的提高了性能，區別在於CLHLock是通過輪詢其前驅節點的狀態，而MCS則是查看當前節點的鎖狀態。
CLHLock在NUMA架構下使用會存在問題。在沒有cache的NUMA系統架構中，由於CLHLock是在當前節點的前一個節點上自旋,NUMA架構中處理器訪問本地內存的速度高於通過網絡訪問其他節點的內存，所以CLHLock在NUMA架構上不是最優的自旋鎖
package concurrency.lock;
public class MCSLock {
/**
* 節點，記錄當前節點的鎖狀態以及後驅節點
*/
public static class MCSNode {
volatile MCSNode next;
volatile boolean isLocked = true;
}
private static final ThreadLocal<MCSNode> NODE = new ThreadLocal<MCSNode>();
// 隊列
@SuppressWarnings("unused")
private volatile MCSNode queue;
// queue更新器
private static final AtomicReferenceFieldUpdater<MCSLock, MCSNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(MCSLock.class, MCSNode.class,
"queue");
public void lock() {
// 創建節點並保存到ThreadLocal中
MCSNode currentNode = new MCSNode();
NODE.set(currentNode);
// 將queue設置爲當前節點，並且返回之前的節點
MCSNode preNode = UPDATER.getAndSet(this, currentNode);
if (preNode != null) {
// 如果之前節點不爲null，表示鎖已經被其他線程持有
preNode.next = currentNode;
// 循環判斷，直到當前節點的鎖標誌位爲false
while (currentNode.isLocked) {
}
}
}
public void unlock() {
MCSNode currentNode = NODE.get();
// next爲null表示沒有正在等待獲取鎖的線程
if (currentNode.next == null) {
// 更新狀態並設置queue爲null
if (UPDATER.compareAndSet(this, currentNode, null)) {
// 如果成功了，表示queue==currentNode,即當前節點後面沒有節點了
return;
} else {
// 如果不成功，表示queue!=currentNode,即當前節點後面多了一個節點，表示有線程在等待
// 如果當前節點的後續節點爲null，則需要等待其不爲null（參考加鎖方法）
while (currentNode.next == null) {
}
}
} else {
// 如果不爲null，表示有線程在等待獲取鎖，此時將等待線程對應的節點鎖狀態更新爲false，同時將當前線程的後繼節點設爲null
currentNode.next.isLocked = false;
currentNode.next = null;
}
}
}