java鎖的兩種機制

Ⅰ java中文件加鎖機制是怎麼實現的。

Java中文件加鎖機制如下：
在對文件操作過程中，有時候需要對文件進行加鎖操作，防止其他線程訪問該文件。對文件的加鎖方法有兩種：
第一種方法：使用RandomAccessFile類操作文件。
在java.io.RandomAccessFile類的open方法，提供了參數實現獨占的方式打開文件：
RandomAccessFile raf = new RandomAccessFile(file, "rws");
其中的「rws」參數，rw代表讀取和寫入，s代表了同步方式，也就是同步鎖。這種方式打開的文件，就是獨占方式的。

第二種方法：使用sun.nio.FileChannel對文件進行加鎖。
代碼：
RandomAccessFile raf = new RandomAccessFile("file.txt", "rw");
FileChannel fc = raf.getChannel();
FileLock fl = fc.tryLock();
if(fl.isValid())
System.out.println("You have got the file lock.");

以上是通過RandomAccessFile來獲得文件鎖的，方法如下：
代碼：
FileOutputStream fos = new FileOutputStream("file.txt");
FileChannel fc = fos.getChannel(); //獲取FileChannel對象
FileLock fl = fc.tryLock(); //or fc.lock();
if(null != fl)
System.out.println("You have got file lock.");
//TODO write content to file
//TODO write end, should release this lock
fl.release(); //釋放文件鎖
fos.close; //關閉文件寫操作

如果在讀文件操作的時候，對文件進行加鎖，操作過程如下：
FileChannel也可以從FileInputStream中直接獲得，但是這種直接獲得FileChannel的對象直接去操作FileLock會報異常NonWritableChannelException，需要自己去實現getChannel方法，代碼如下：
private static FileChannel getChannel(FileInputStream fin, FileDescriptor fd) {
FileChannel channel = null;
synchronized(fin){
channel = FileChannelImpl.open(fd, true, true, fin);
return channel;
}
}

其實，看FileInputStream時，發現getChannel方法與我們寫的代碼只有一個地方不同，即open方法的第三個參數不同，如果設置為false，就不能鎖住文件了。預設的getChannel方法，就是false，因此，不能鎖住文件。

Ⅱ 如何使用java的鎖機制

可以在臨界區代碼開始的位置執行Lock類的lock方法，為代碼塊加鎖，而在臨界區的出口使用相同Lock實例的unlock方法，釋放臨界區資源。
Demo2-12中，主線程先創建了一個lockTest對象test，然後將相同的test對象交給兩個不同的線程執行。子線程1獲取到了lock後，開始執行before sleep輸出語句，遇到sleep後，線程1阻塞將會放棄執行權，這時線程2可以獲取執行權，當線程2執行lock方法時，發現鎖已經被別的線程獲取，所以線程2阻塞等待lock的釋放。線程1從sleep中被喚醒後，將繼續執行after sleep語句，之後釋放了鎖，此時線程2從鎖等待中被喚醒，執行臨近區的內容，因此Demo2-12的輸出是先線程1的兩條語句，之後才輸出線程2的兩條語句。而Demo2-13在沒有鎖的保護下，程序無法保證先將線程1的兩條語句輸出後再執行線程2的輸出，因此，Demo2-13的輸出結果是交叉的。

Ⅲ java中snchronised和鎖的區別

在分布式開發中，鎖是線程式控制制的重要途徑。Java為此也提供了2種鎖機制，synchronized和lock。
我們先從最簡單的入手，逐步分析這2種的區別。

一、synchronized和lock的用法區別

synchronized：在需要同步的對象中加入此控制，synchronized可以加在方法上，也可以加在特定代碼塊中，括弧中表示需要鎖的對象。

lock：需要顯示指定起始位置和終止位置。一般使用ReentrantLock類做為鎖，多個線程中必須要使用一個ReentrantLock類做為對象才能保證鎖的生效。且在加鎖和解鎖處需要通過lock()和unlock()顯示指出。所以一般會在finally塊中寫unlock()以防死鎖。

用法區別比較簡單，這里不贅述了，如果不懂的可以看看Java基本語法。

二、synchronized和lock性能區別

synchronized是託管給JVM執行的，而lock是java寫的控制鎖的代碼。在Java1.5中，synchronize是性能低效的。因為這是一個重量級操作，需要調用操作介面，導致有可能加鎖消耗的系統時間比加鎖以外的操作還多。相比之下使用Java提供的Lock對象，性能更高一些。但是到了Java1.6，發生了變化。synchronize在語義上很清晰，可以進行很多優化，有適應自旋，鎖消除，鎖粗化，輕量級鎖，偏向鎖等等。導致在Java1.6上synchronize的性能並不比Lock差。官方也表示，他們也更支持synchronize，在未來的版本中還有優化餘地。

說到這里，還是想提一下這2中機制的具體區別。據我所知，synchronized原始採用的是CPU悲觀鎖機制，即線程獲得的是獨占鎖。獨占鎖意味著其他線程只能依靠阻塞來等待線程釋放鎖。而在CPU轉換線程阻塞時會引起線程上下文切換，當有很多線程競爭鎖的時候，會引起CPU頻繁的上下文切換導致效率很低。

而Lock用的是樂觀鎖方式。所謂樂觀鎖就是，每次不加鎖而是假設沒有沖突而去完成某項操作，如果因為沖突失敗就重試，直到成功為止。樂觀鎖實現的機制就是CAS操作（Compare and Swap）。我們可以進一步研究ReentrantLock的源代碼，會發現其中比較重要的獲得鎖的一個方法是compareAndSetState。這里其實就是調用的CPU提供的特殊指令。

現代的CPU提供了指令，可以自動更新共享數據，而且能夠檢測到其他線程的干擾，而 compareAndSet() 就用這些代替了鎖定。這個演算法稱作非阻塞演算法，意思是一個線程的失敗或者掛起不應該影響其他線程的失敗或掛起的演算法。

我也只是了解到這一步，具體到CPU的演算法如果感興趣的讀者還可以在查閱下，如果有更好的解釋也可以給我留言，我也學習下。

三、synchronized和lock用途區別

synchronized原語和ReentrantLock在一般情況下沒有什麼區別，但是在非常復雜的同步應用中，請考慮使用ReentrantLock，特別是遇到下面2種需求的時候。

1.某個線程在等待一個鎖的控制權的這段時間需要中斷
2.需要分開處理一些wait-notify，ReentrantLock裡面的Condition應用，能夠控制notify哪個線程
3.具有公平鎖功能，每個到來的線程都將排隊等候

Ⅳ java的加鎖機制的問題，簡單回答一下就好

每個對象有唯一的一把鎖。鎖被某個線程獲得後，其他線程會阻塞等待，直到鎖被釋放且獲得。
語法
synchronize(對象){
....
}，意思就是當前線程需要獲得該對象的鎖才能運行之後同步塊中的代碼，沒獲得就阻塞等待。
這樣就避免對該對象同時有多個線程讀寫，造成數據不同步的問題，從而實現了「同步synchronization」

Ⅳ java中悲觀鎖和樂觀鎖的區別

樂觀鎖和悲觀鎖的區別如下：
1、悲觀鎖是當線程拿到資源時，就對資源上鎖，並在提交後，才釋放鎖資源，其他線程才能使用資源。
2、樂觀鎖是當線程拿到資源時，上樂觀鎖，在提交之前，其他的鎖也可以操作這個資源，當有沖突的時候，並發機制會保留前一個提交，打回後一個提交，讓後一個線程重新獲取資源後，再操作，然後提交。和git上傳代碼一樣，兩個線程都不是直接獲取資源本身，而是先獲取資源的兩個版本，然後在這兩個版本上修改。
3、悲觀鎖和樂觀鎖在並發量低的時候，性能差不多，但是在並發量高的時候，樂觀鎖的性能遠遠優於悲觀鎖。
4、常用的synchronized是悲觀鎖，lock是樂觀鎖。

Ⅵ java 鎖有幾種

樂觀鎖/悲觀鎖

樂觀鎖與悲觀鎖不是指具體的什麼類型的鎖，而是指看待並發同步的角度。

悲觀鎖認為對於同一個數據的並發操作，一定是會發生修改的，哪怕沒有修改，也會認為修改。因此對於同一個數據的並發操作，悲觀鎖採取加鎖的形式。悲觀的認為，不加鎖的並發操作一定會出問題。
樂觀鎖則認為對於同一個數據的並發操作，是不會發生修改的。在更新數據的時候，會採用嘗試更新，不斷重新的方式更新數據。樂觀的認為，不加鎖的並發操作是沒有事情的。
從上面的描述我們可以看出，悲觀鎖適合寫操作非常多的場景，樂觀鎖適合讀操作非常多的場景，不加鎖會帶來大量的性能提升。
公平鎖/非公平鎖

公平鎖是指多個線程按照申請鎖的順序來獲取鎖。

非公平鎖是指多個線程獲取鎖的順序並不是按照申請鎖的順序，有可能後申請的線程比先申請的線程優先獲取鎖。

優點：在於吞吐量比公平鎖大。
缺點：可能會造成優先順序反轉或者某些線程飢餓現象(一直拿不到鎖)。
對於Java ReentrantLock而言，通過構造函數指定該鎖是否是公平鎖，默認是非公平鎖。
對於Synchronized而言，也是一種非公平鎖。由於其並不像ReentrantLock是通過AQS的來實現線程調度，所以並沒有任何辦法使其變成公平鎖。
可重入鎖

可重入鎖的概念是自己可以再次獲取自己的內部鎖。
舉個例子，比如一條線程獲得了某個對象的鎖，此時這個對象鎖還沒有釋放，當其再次想要獲取這個對象的鎖的時候還是可以獲取的（如果不可重入的鎖的話，此刻會造成死鎖）。說的更高深一點可重入鎖是一種遞歸無阻塞的同步機制。
對於Java ReentrantLock而言, 他的名字就可以看出是一個可重入鎖，其名字是Re entrant Lock重新進入鎖。
對於Synchronized而言,也是一個可重入鎖。可重入鎖的一個好處是可一定程度避免死鎖。
獨享鎖/共享鎖

獨享鎖是指該鎖一次只能被一個線程所持有。
共享鎖是指該鎖可被多個線程所持有。
對於Java ReentrantLock（互斥鎖）而言，其是獨享鎖。
但是對於Lock的另一個實現類ReadWriteLock（讀寫鎖），其讀鎖是共享鎖，其寫鎖是獨享鎖。讀鎖的共享鎖可保證並發讀是非常高效的，讀寫，寫讀 ，寫寫的過程是互斥的。
對於Synchronized而言，當然是獨享鎖。
分段鎖

分段鎖其實是一種鎖的設計，並不是具體的一種鎖。對於ConcurrentHashMap而言，其並發的實現就是通過分段鎖的形式來實現高效的並發操作。

我們以ConcurrentHashMap來說一下分段鎖的含義以及設計思想，ConcurrentHashMap中的分段鎖稱為Segment，它即類似於HashMap（JDK7與JDK8中HashMap的實現）的結構，即內部擁有一個Entry數組，數組中的每個元素又是一個鏈表；同時又是一個ReentrantLock（Segment繼承了ReentrantLock)。
當需要put元素的時候，並不是對整個hashmap進行加鎖，而是先通過hashcode來知道他要放在那一個分段中，然後對這個分段進行加鎖，所以當多線程put的時候，只要不是放在一個分段中，就實現了真正的並行的插入。
但是，在統計size的時候，可就是獲取hashmap全局信息的時候，就需要獲取所有的分段鎖才能統計。
分段鎖的設計目的是細化鎖的粒度，當操作不需要更新整個數組的時候，就僅僅針對數組中的一項進行加鎖操作。
互斥鎖：

無法獲取瑣時，進線程立刻放棄剩餘的時間片並進入阻塞（或者說掛起）狀態，同時保存寄存器和程序計數器的內容（保存現場，上下文切換的前半部分），當可以獲取鎖時，進線程激活，等待被調度進CPU並恢復現場（上下文切換下半部分）

上下文切換會帶來數十微秒的開銷，不要在性能敏感的地方用互斥鎖
讀寫鎖：

1）多個讀者可以同時進行讀
2）寫者必須互斥（只允許一個寫者寫，也不能讀者寫者同時進行）
3）寫者優先於讀者（一旦有寫者，則後續讀者必須等待，喚醒時優先考慮寫者）
自旋鎖：

自旋鎖是指嘗試獲取鎖的線程不會立即阻塞，而是採用循環的方式去嘗試獲取鎖，這樣的好處是減少線程上下文切換的消耗，缺點是循環會消耗CPU。

Ⅶ 說說java鎖有哪些種類，以及區別

鎖作為並發共享數據，保證一致性的工具，在JAVA平台有多種實現(如 synchronized 和 ReentrantLock等等 ) 。這些已經寫好提供的鎖為我們開發提供了便利，但是鎖的具體性質以及類型卻很少被提及。本系列文章將分析JAVA下常見的鎖名稱以及特性，為大家答疑解惑。
1、自旋鎖
自旋鎖是採用讓當前線程不停地的在循環體內執行實現的，當循環的條件被其他線程改變時 才能進入臨界區。如下

01 public class SpinLock {
02
03 private AtomicReference<Thread> sign =newAtomicReference<>();
04
05 public void lock(){
06 Thread current = Thread.currentThread();
07 while(!sign .compareAndSet(null, current)){
08 }
09 }
10
11 public void unlock (){
12 Thread current = Thread.currentThread();
13 sign .compareAndSet(current, null);
14 }
15 }
使用了CAS原子操作，lock函數將owner設置為當前線程，並且預測原來的值為空。unlock函數將owner設置為null，並且預測值為當前線程。
當有第二個線程調用lock操作時由於owner值不為空，導致循環一直被執行，直至第一個線程調用unlock函數將owner設置為null，第二個線程才能進入臨界區。
由於自旋鎖只是將當前線程不停地執行循環體，不進行線程狀態的改變，所以響應速度更快。但當線程數不停增加時，性能下降明顯，因為每個線程都需要執行，佔用CPU時間。如果線程競爭不激烈，並且保持鎖的時間段。適合使用自旋鎖。
註：該例子為非公平鎖，獲得鎖的先後順序，不會按照進入lock的先後順序進行。
Java鎖的種類以及辨析（二）：自旋鎖的其他種類

鎖作為並發共享數據，保證一致性的工具，在JAVA平台有多種實現(如 synchronized 和 ReentrantLock等等 ) 。這些已經寫好提供的鎖為我們開發提供了便利，但是鎖的具體性質以及類型卻很少被提及。本系列文章將分析JAVA下常見的鎖名稱以及特性，為大家答疑解惑。

2.自旋鎖的其他種類
上篇我們講到了自旋鎖，在自旋鎖中 另有三種常見的鎖形式:TicketLock ，CLHlock 和MCSlock
Ticket鎖主要解決的是訪問順序的問題，主要的問題是在多核cpu上
01 package com.alipay.titan.dcc.dal.entity;
02
03 import java.util.concurrent.atomic.AtomicInteger;
04
05 public class TicketLock {
06 private AtomicInteger serviceNum = new AtomicInteger();
07 private AtomicInteger ticketNum = new AtomicInteger();
08 private static final ThreadLocal<Integer> LOCAL = new ThreadLocal<Integer>();
09
10 public void lock() {
11 int myticket = ticketNum.getAndIncrement();
12 LOCAL.set(myticket);
13 while (myticket != serviceNum.get()) {
14 }
15
16 }
17
18 public void unlock() {
19 int myticket = LOCAL.get();
20 serviceNum.compareAndSet(myticket, myticket + 1);
21 }
22 }
每次都要查詢一個serviceNum 服務號，影響性能（必須要到主內存讀取，並阻止其他cpu修改）。
CLHLock 和MCSLock 則是兩種類型相似的公平鎖，採用鏈表的形式進行排序，
01 importjava.util.concurrent.atomic.AtomicReferenceFieldUpdater;
02
03 public class CLHLock {
04 public static class CLHNode {
05 private volatile boolean isLocked = true;
06 }
07
08 @SuppressWarnings("unused")
09 private volatileCLHNode tail;
10 private static finalThreadLocal<CLHNode> LOCAL = new ThreadLocal<CLHNode>();
11 private static <CLHLock, CLHNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(CLHLock.class,
12 CLHNode.class,"tail");
13
14 public void lock() {
15 CLHNode node = new CLHNode();
16 LOCAL.set(node);
17 CLHNode preNode = UPDATER.getAndSet(this, node);
18 if (preNode != null) {
19 while (preNode.isLocked) {
20 }
21 preNode = null;
22 LOCAL.set(node);
23 }
24 }
25
26 public void unlock() {
27 CLHNode node = LOCAL.get();
28 if (!UPDATER.compareAndSet(this, node,null)) {
29 node.isLocked = false;
30 }
31 node = null;
32 }
33 }

CLHlock是不停的查詢前驅變數， 導致不適合在NUMA 架構下使用（在這種結構下，每個線程分布在不同的物理內存區域）
MCSLock則是對本地變數的節點進行循環。不存在CLHlock 的問題。
01 importjava.util.concurrent.atomic.AtomicReferenceFieldUpdater;
02
03 public class MCSLock {
04 public static class MCSNode {
05 volatile MCSNode next;
06 volatile boolean isLocked = true;
07 }
08
09 private static finalThreadLocal<MCSNode> NODE = new ThreadLocal<MCSNode>();
10 @SuppressWarnings("unused")
11 private volatileMCSNode queue;
12 private static <MCSLock, MCSNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(MCSLock.class,
13 MCSNode.class,"queue");
14
15 public void lock() {
16 MCSNode currentNode = new MCSNode();
17 NODE.set(currentNode);
18 MCSNode preNode = UPDATER.getAndSet(this, currentNode);
19 if (preNode != null) {
20 preNode.next = currentNode;
21 while (currentNode.isLocked) {
22
23 }
24 }
25 }
26
27 public void unlock() {
28 MCSNode currentNode = NODE.get();
29 if (currentNode.next == null) {
30 if (UPDATER.compareAndSet(this, currentNode, null)) {
31
32 } else {
33 while (currentNode.next == null) {
34 }
35 }
36 } else {
37 currentNode.next.isLocked = false;
38 currentNode.next = null;
39 }
40 }
41 }

Ⅷ java的鎖機制，到底都能鎖住啥

這是有關線程的概念，多線程在訪問同一數據或代碼塊的時候可能造成數據不一致，即線程不安全，此時需要線程鎖，有鎖就一次只能一個線程訪問，做到保證數據的一致性，下個線程只有在前面的線程執行完之後把鎖釋放才能訪問

Ⅸ 北大青鳥java培訓：關於線程安全問題分析

在學習java編程開發語言的過程中，我們掌握了線程與線程池等相關技術知識。
今天，北大青鳥湖南計算機學院http://www.kmbdqn.cn/就關於線程安全問題給大家做一個簡單的說明和介紹，一起來了解一下吧。
線程安全就是多線程訪問時，採用了加鎖機制，當一個線程訪問該類的某個數據時，進行保護，其他線程不能進行訪問直到該線程讀取完，其他線程才可使用。
不會出現數據不一致或者數據污染。
線程不安全就是不提供數據訪問保護，有可能出現多個線程先後更改數據造成所得到的數據是臟數據。
什麼時候考慮到線程安全：一個對象是否需要線程安全，取決於該對象是否被多線程訪問。
這指的是程序中訪問對象的方式，而不是對象要實現的功能。
要使得對象是線程安全的，要採用同步機制來協同對對象可變狀態的訪問。
Java常用的同步機制是Synchronized，還包括volatile類型的變數，顯示鎖以及原子變數。
在多個線程中，當它們同時訪問同個類時，每次執行的結果和單線程結果一致，且變數值跟預期一致，這個類則是線程安全的。
鎖的特性鎖機制的兩種特性：互斥性：即同一時間只允許一個線程持有某個對象的鎖，通過這種特性來實現多線程中的協調機制，這樣在同一時間只有一個線程對需同步的代碼塊(復合操作)進行訪問。
互斥性我們也往往稱為操作的原子性。
可見性：必須確保在鎖被釋放之前，對共享變數所做的修改，對於隨後獲得該鎖的另一個線程是可見的，否則另一個線程可能是在本地緩存的某個副本上繼續操作從而引起不一致。
掛起、休眠、阻塞和非阻塞掛起：當線程被掛起時，其會失去CPU的使用時間，直到被其他線程(用戶線程或調試線程)喚醒。
休眠：同樣是會失去CPU的使用時間，但是在過了指定的休眠時間之後，它會自動激活，無需喚醒(整個喚醒表面看是自動的，但實際上也得有守護線程去喚醒，只是不需編程者手動干預)。
阻塞：在線程執行時，所需要的資源不能得到，則線程被掛起，直到滿足可操作的條件。
非阻塞：在線程執行時，所需要的資源不能得到，則線程不是被掛起等待，而是繼續執行其餘事情，等待條件滿足了後，收到了通知(同樣是守護線程去做)再執行。

Ⅹ JAVA中的內鎖機制是什麼

多線程同步的實現最終依賴鎖機制。我們可以想像某一共享資源是一間屋子，每個人都是一個線程。當A希望進入房間時，他必須獲得門鎖，一旦A獲得門鎖，他進去後就立刻將門鎖上，於是B,C,D...就不得不在門外等待，直到A釋放鎖出來後，B,C,D...中的某一人搶到了該鎖（具體搶法依賴於JVM的實現，可以先到先得，也可以隨機挑選），然後進屋又將門鎖上。這樣，任一時刻最多有一人在屋內（使用共享資源）。 Java語言規范內置了對多線程的支持。對於Java程序來說，每一個對象實例都有一把「鎖」，一旦某個線程獲得了該鎖，別的線程如果希望獲得該鎖，只能等待這個線程釋放鎖之後。獲得鎖的方法只有一個，就是synchronized關鍵字。