Ⅰ 在java中有哪些鎖
給你整理了Java中的一些鎖：
公平鎖/非公平鎖
可重入鎖
獨享鎖/共享鎖
互斥鎖/讀寫鎖
樂觀鎖/悲觀鎖
分段鎖
偏向鎖/輕量級鎖/重量級鎖
自旋鎖
上面是很多鎖的名詞，這些分類並不是全是指鎖的狀態，有的指鎖的特性，有的指鎖的設計
Ⅱ java多線程『鎖』,是用什麼鎖的,有方法
synchronized關鍵字可以讓你對一個對象加鎖，
比如synchronized(this);表示對當前類對象加鎖，這是一個排他所，即只有一個線程可以訪問被synchronized的對象
Ⅲ java中的鎖有哪幾種
lock比synchronized比較如下：
1) 支持公平鎖，某些場景下需要獲得鎖的時間與申請鎖的時間相一致，但是synchronized做不到
2) 支持中斷處理，就是說那些持有鎖的線程一直不釋放，正在等待的線程可以放棄等待。如果不支持中斷處理，那麼線程可能一直無限制的等待下去，就算那些正在佔用資源的線程死鎖了，正在等待的那些資源還是會繼續等待，但是ReentrantLock可以選擇放棄等待
3) condition和lock配合使用，以獲得最大的性能
JAVA中鎖使用的幾點建議：
1.如果沒有特殊的需求，建議使用synchronized，因為操作簡單，便捷，不需要額外進行鎖的釋放。鑒於JDK1.8中的ConcurrentHashMap也使用了CAS+synchronized的方式替換了老版本中使用分段鎖（ReentrantLock）的方式，可以得知，JVM中對synchronized的性能做了比較好的優化。
2.如果代碼中有特殊的需求，建議使用Lock。例如並發量比較高，且有些操作比較耗時，則可以使用支持中斷的所獲取方式；如果對於鎖的獲取，講究先來後到的順序則可以使用公平鎖；另外對於多個變數的鎖保護可以通過lock中提供的condition對象來和lock配合使用，獲取最大的性能。
Ⅳ Java中有哪些鎖，區別是什麼
【1】公平所和非公平所。
公平鎖：是指按照申請鎖的順序來獲取鎖，
非公平所：線程獲取鎖的順序不一定按照申請鎖的順序來的。
//默認是不公平鎖，傳入true為公平鎖，否則為非公平鎖
ReentrantLock reentrantLock = new ReetrantLock();
1
2
【2】共享鎖和獨享鎖
獨享鎖：一次只能被一個線程所訪問
共享鎖：線程可以被多個線程所持有。
ReadWriteLock 讀鎖是共享鎖，寫鎖是獨享鎖。
【3】樂觀鎖和悲觀鎖。
樂觀鎖：對於一個數據的操作並發，是不會發生修改的。在更新數據的時候，會嘗試採用更新，不斷重入的方式，更新數據。
悲觀鎖：對於同一個數據的並發操作，是一定會發生修改的。因此對於同一個數據的並發操作，悲觀鎖採用加鎖的形式。悲觀鎖認為，不加鎖的操作一定會出問題，
【4】分段鎖
1.7及之前的concurrenthashmap。並發操作就是分段鎖，其思想就是讓鎖的粒度變小。
【5】偏向鎖是指一段同步代碼一直被一個線程所訪問，那麼該線程會自動獲取鎖。降低獲取鎖的代價
輕量級鎖
重量級鎖
【6】自旋鎖
自旋鎖
Ⅳ Java 集群鎖如何實現
1. 用資料庫，在資料庫建一張表，需要鎖的節點都可以嘗試用 select * from Lock where id=xx for update. 這個時候只有一個節點能拿到結果，其它的都會等待，就能實現一個簡單的悲觀鎖。
2. 用 Zookeeper 來做分布式鎖，具體可以搜一下。
3. 自己實現，搞個節點來做這個事情，所有要獲取鎖的都走 RPC 調用來請求鎖，用完以後記得釋放，不然其他的節點就會掛那裡。
Ⅵ JAVA多線程中「鎖」的概念的理解
當有多個線程共用一種臨界資源的時候，便會出現沖突，鎖就是用來解決這種沖突的，跟上廁所一樣，假如有ABC三個人都來上廁所而廁所只有一個一次只能進一人，A先來了，那麼在A出來之前，這個廁所就處在了「鎖」定狀態，B和C憋死也要在外面等著，直到A出門（原因很多，如睡著了，方便完了，忘帶廁紙了跑出來找人要....）「鎖」定解除B和C才能進入，當然牛逼的進（A和B有一腿只讓B進或者優先順序高或者...），SB的在外面繼續等。此乃吾理解之鎖定，希望能夠對你有所幫助
Ⅶ java集群下定時任務，怎麼保證任務只執行一次啊
用redis分布式鎖就可以搞定，因為redis對於集群是共享的
Ⅷ java怎麼實現redis分布式鎖
Redis有一系列的命令，特點是以NX結尾，NX是Not eXists的縮寫，如SETNX命令就應該理解為：SET if Not eXists。這系列的命令非常有用，這里講使用SETNX來實現分布式鎖。
用SETNX實現分布式鎖
利用SETNX非常簡單地實現分布式鎖。例如：某客戶端要獲得一個名字foo的鎖，客戶端使用下面的命令進行獲取：
SETNX lock.foo <current Unix time + lock timeout + 1>
如返回1，則該客戶端獲得鎖，把lock.foo的鍵值設置為時間值表示該鍵已被鎖定，該客戶端最後可以通過DEL lock.foo來釋放該鎖。
如返回0，表明該鎖已被其他客戶端取得，這時我們可以先返回或進行重試等對方完成或等待鎖超時。
解決死鎖
上面的鎖定邏輯有一個問題：如果一個持有鎖的客戶端失敗或崩潰了不能釋放鎖，該怎麼解決？我們可以通過鎖的鍵對應的時間戳來判斷這種情況是否發生了，如果當前的時間已經大於lock.foo的值，說明該鎖已失效，可以被重新使用。
發生這種情況時，可不能簡單的通過DEL來刪除鎖，然後再SETNX一次，當多個客戶端檢測到鎖超時後都會嘗試去釋放它，這里就可能出現一個競態條件,讓我們模擬一下這個場景：
C0操作超時了，但它還持有著鎖，C1和C2讀取lock.foo檢查時間戳，先後發現超時了。
C1 發送DEL lock.foo
C1 發送SETNX lock.foo 並且成功了。
C2 發送DEL lock.foo
C2 發送SETNX lock.foo 並且成功了。
這樣一來，C1，C2都拿到了鎖！問題大了！
幸好這種問題是可以避免D，讓我們來看看C3這個客戶端是怎樣做的：
C3發送SETNX lock.foo 想要獲得鎖，由於C0還持有鎖，所以Redis返回給C3一個0
C3發送GET lock.foo 以檢查鎖是否超時了，如果沒超時，則等待或重試。
反之，如果已超時，C3通過下面的操作來嘗試獲得鎖：
GETSET lock.foo <current Unix time + lock timeout + 1>
通過GETSET，C3拿到的時間戳如果仍然是超時的，那就說明，C3如願以償拿到鎖了。
如果在C3之前，有個叫C4的客戶端比C3快一步執行了上面的操作，那麼C3拿到的時間戳是個未超時的值，這時，C3沒有如期獲得鎖，需要再次等待或重試。留意一下，盡管C3沒拿到鎖，但它改寫了C4設置的鎖的超時值，不過這一點非常微小的誤差帶來的影響可以忽略不計。
注意：為了讓分布式鎖的演算法更穩鍵些，持有鎖的客戶端在解鎖之前應該再檢查一次自己的鎖是否已經超時，再去做DEL操作，因為可能客戶端因為某個耗時的操作而掛起，操作完的時候鎖因為超時已經被別人獲得，這時就不必解鎖了。
示例偽代碼
根據上面的代碼，我寫了一小段Fake代碼來描述使用分布式鎖的全過程：
# get lock
lock = 0
while lock != 1:
timestamp = current Unix time + lock timeout + 1
lock = SETNX lock.foo timestamp
if lock == 1 or (now() > (GET lock.foo) and now() > (GETSET lock.foo timestamp)):
break;
else:
sleep(10ms)
# do your job
do_job()
# release
if now() < GET lock.foo:
DEL lock.foo
是的，要想這段邏輯可以重用，使用python的你馬上就想到了Decorator，而用Java的你是不是也想到了那誰？AOP + annotation？行，怎樣舒服怎樣用吧，別重復代碼就行。
Ⅸ java 集群
一旦在伺服器上安裝並運行了群集服務 ， 該伺服器即可加入群集。群集化操作可以減少單點故障數量，並且實現了群集化資源的高可用性。下述各節簡要介紹了群集創建和群集操作中的節點行為。
注意 ： 有關安裝群集伺服器的信息 ， 請參閱 Windows server 2003 產品家族的幫助和部署指南。
創建群集
在伺服器群集產品中含有用來在伺服器上安裝群集軟體和創建新群集的群集安裝實用工具。創建新群集時，首先在選擇作為群集的第一個成員的計算機上運行該實用工具。第一步是確定群集名稱並創建群集資料庫和初始的群集成員列表來定義新群集。 Windows server 2003 群集新增了一個群集管理設置向導以及使用 cluster.exe 命令行界面創建 （ 包括從遠程創建 ） 群集的功能。
創建群集的第二步是 ， 添加可供所有群集成員使用的共用數據存儲設備。這樣，創建的新群集將帶有一個節點、自己的本地數據存儲設備以及群集共用資源 —— 通常是磁碟或數據存儲和連接介質資源。
創建群集的最後一步是 ， 在另外將要成為群集成員的每一台計算機上運行安裝實用工具。每當將新節點添加到群集中時，新節點都會自動從群集的原始成員獲得現有群集資料庫的副本。當節點加入或形成群集時，群集服務會更新該節點私有的配置資料庫副本。
形成群集
如果伺服器運行了群集服務並且無法找到群集中的其它節點 ， 它自己可以形成一個群集。要形成群集，節點必須能夠獲得對仲裁資源的獨占權。
當最初形成群集時 ， 群集中的第一個節點將包括群集配置資料庫。每當有新節點加入群集時，新節點都會在本地獲得並保持群集配置資料庫的副本。仲裁資源用恢復日誌（其中含有同節點無關的群集配置和狀態數據）的形式存儲配置資料庫的最新版本。
在群集運行中 ， 群集服務使用仲裁恢復日誌執行以下操作 ：
• 保證只有一組活動、可相互通訊的節點才能形成群集
• 僅當某個節點可以獲得對仲裁資源的控制權時 ， 才允許它形成群集
• 僅當某個節點可以同控制仲裁資源的節點通訊時 ， 才允許它加入或留在現有群集中
從群集中的其它節點和群集服務管理介面的角度看 ， 當形成群集時 ， 群集中的每個節點可能處於三種不同狀態中的一種。事件處理器會記錄這些狀態，而事件日誌管理器會將這些狀態復制到群集的其它節點。群集服務狀態包括：
• 離線 。此時的節點不是完全有效的群集成員。該節點及其群集伺服器可能在運行，也可能未運行。
• 聯機 。此時的節點是完全有效的群集成員。它遵從群集資料庫的更新、對仲裁演算法施加自己的影響、維護心跳通訊，並可以擁有和運行資源組。
• 暫停 。此時的節點是完全有效的群集成員。它遵從群集資料庫的更新、對仲裁演算法施加自己的影響、維護心跳通訊，但它無法接受資源組。它只能支持它當前已擁有的那些資源組。之所以提供暫停狀態，是為了允許執行某些維護。大多數伺服器群集組件會將聯機和暫停視為等價的狀態。
加入群集
如果一個伺服器要加入現有群集 ， 則它必須運行群集服務並且必須成功找到群集中的其它節點。在找到其它節點後，加入的伺服器必須接受群集成員資格驗證，並獲得群集配置資料庫的副本。
加入現有群集的過程開始於 Windows Server 2003 或 Windows 2000 Service Control Manager 在節點上啟動群集服務之時。在啟動過程中，群集服務會配置並裝入該節點的本地數據設備。它並不會試圖將共用的群集數據設備作為節點聯機，因為現有群集可能正在使用這些設備。
為了查找其它節點 ， 會啟動一個發現過程。當節點發現任何群集成員時，它將執行身份驗證序列。第一個群集成員會對新加入者進行身份驗證，並且在新伺服器得到成功驗證後返回成功狀態。如果驗證不成功（未能識別待加入節點的群集成員身份，或者它使用了無效的帳戶密碼），則加入群集的請求會被拒絕。
進行成功驗證後 ， 首先聯機的群集節點會檢查加入節點上的配置資料庫副本。如果該副本已過時，對加入伺服器進行驗證的群集節點會為加入的伺服器發送該資料庫的更新副本。剛加入群集的節點在收到復制的資料庫後，可以用它查找共享資源並根據需要將它們聯機。
脫離群集
當節點關閉或群集服務被停止時 ， 節點可能脫離群集。但當節點不執行群集操作（比如不向群集配置資料庫提交更新）時，節點也可能被迫脫離（被逐出）群集。
如果節點根據預先的計劃脫離群集 ， 它會向其它所有節點成員發送 ClusterExit 消息 ， 通知它們它將脫離群集。該節點不等待任何響應就會立即進行關閉資源和所有群集連接的操作。由於其餘節點收到了退出消息，因此它們不會執行在節點意外失效或網路通訊停止時發生的重新分組過程以重新確立群集成員身份。
[ 本日：2 本周：2 本月：60 總瀏覽數：128 ] [返回上一頁] [打 印] [收 藏]
上一篇文章：故障檢測和相關鏈接
下一篇文章：windows 2000活動目錄詳解之安裝配置篇
Ⅹ Java多線程加鎖的問題
publicclassTest{
publicstaticvoidmain(String[]args)throwsInterruptedException{
System.out.println("2個線程開始執行....");
TestHellohello1=newTestHello("A",1000);
TestHellohello2=newTestHello("B",2000);
Threaddemo1=newThread(hello1);
Threaddemo2=newThread(hello2);
demo1.start();
demo2.start();
try{
demo1.join();
demo2.join();
}finally{
System.out.println("線程均執行完成....");
}
}
}
{
privateStringworkname;
privateintworktime;
//省略workname和worktime的set和get方法
publicTestHello(Stringworkname,intworktime){
super();
this.workname=workname;
this.worktime=worktime;
}
publicvoidrun(){
for(inti=0;i<5;i++){
System.out.println(this.workname+"運行"+i);
try{
Thread.sleep(worktime);
}catch(InterruptedExceptione){
e.printStackTrace();
}
}
}
}