@mitisky
入隊列enq 是一個CAS操作，如果加入隊列成功，會立即進行隊列自旋操作，在這個操作里面嘗試獲取鎖。
參考：
http://m.tkk7.com/xylz/archive/2010/07/07/325410.htmlacquireQueued(node,arg)
re: Java進程由于系統內存不足被殺掉的證據 imxylz 2015-06-16 10:51
re: 捕獲Java線程池執行任務拋出的異常 imxylz 2015-05-13 10:37
@liubey
友好的做法是子線程不拋出異常，返回不同的結果，或者將異常封裝到return對象中。父對象根據此結果/異常封裝友好的提示給界面。
@vanjayzhou
CAS的CPU原語保證A修改時，T2修改會失敗。所以T2才需要循環操作，直到成功。
JDK6以后對synchronized進行了很多優化，而Lock基本上沒有什么可優化的空間。在某些操作系統和JDK實現上，這種簡單的測試結果可能都不一樣。但通常情況下，高并發和長時間任務執行上，Lock的性能比synchronized的更優。
@徐敏
鎖數據結構的實現，便于程序開發。鎖也是基于CAS原子操作實現的，但是CAS難以使用。
@nemo
當提交一個任務時，如果需要創建一個線程（何時需要在下一節中探討）時，就調用線程工廠創建一個線程，同時將線程綁定到Worker工作隊列中。
線程池有兩個核心變量：corePoolSize與maximumPoolSize。
下一頁描述的比較詳細：
http://m.tkk7.com/xylz/archive/2011/02/11/344091.html
@laobailong
建議你學習下final的語法和用途
re: 一個查找jar包中類的小工具 imxylz 2014-02-27 20:45
@程序員
網站不錯。我當年是為了搜索本地，我們自己的類而使用的。我們最開始一直用ant，沒有使用maven，主要是我們內網無法上外網。
re: JRebel 5.5.0 Crack imxylz 2014-02-24 10:09
@tpb
sorry for delay
@newsame
@alec
@小螞蟻
@小寶
@forexi
@ymsfd
@jeridge
已發送
re: JRebel 5.5.0 Crack imxylz 2014-02-20 13:35
@chenhb
難道是新版本eclipse插件？
選擇1：無視它，Eclipse的程序啟動參數加入自定義即可
選擇2：使用5.5.0版本
re: JRebel 5.5.0 Crack imxylz 2014-02-05 13:11
@Avan
@Leo
@Miccie
@javaworld
@jaychang
@mgcnrx11
@Alex
@dada
都已經發送了
@DarrenLee
我直接把這些都刪掉了，怪不得沒看到，太惡心了~~~
@dizzyangel
@libratears
@麒程
@sam
可以繼續使用3.3 版本的，此版本一直能使用。
3.4 （2013）版本暫時不能公開，得讓人家售賣一段時間吧。
@melin
目前只在北京招聘，如果有理想沖動，地域應該不是問題
@zqh
不限條件，只需一份簡歷即可，當前前提是自己覺得值得嘗試下。
re: Java 8 入門/新特性 imxylz 2013-10-16 10:46
@Unmi
非常棒，有深度有真相
re: Crack JRebel 5.3.1 imxylz 2013-08-26 15:53
@Christine
需要將jrebel.lic 放入~/.jrebel/ 目錄中
re: Java多線程對耗時方法的同步問題 imxylz 2013-01-16 10:13
既然是非線程安全的代碼，必然需要同步，這樣多線程執行和單線程沒有分別。改寫代碼為線程安全才是正確的道理。
實在沒有辦法，應該降低handleBusiness里面的鎖的粒度，最終需要同步的邏輯越少越好。
@icanfly#lpnote.com
@girltoyou#gmail.com
@lrenveng#gmail.com
@69202158#qq.com
@iacts29#nate.com
@okok800#gmail.com
@inaquer01#gmail.com
@s870289#yahoo.com.tw
The new packages were sent.
@Newlife
我就花了三個小時，人家挺厚道的，沒有使用混淆機制。大度~
@Newlife
@enchanter
@ygbx5174
@kafei
@footway
@sprnza
@ifans
@jack
@summer
@xmind fans
@shmily
@shen
@aoi
多謝各位的厚愛，由于現在的破解都是無限制版，太坑人家了，畢竟人家一個團隊為此付出了很大的努力。
我爭取盡快出一個時間限制版，這樣能夠在短時間保護一下人家的利益。
re: 分布式消息系統jafka快速起步 imxylz 2012-05-18 15:55
re: 分布式消息系統jafka快速起步 imxylz 2012-05-17 18:51
@樂百事
已經提交到Maven中央倉庫
@imxylz
@紅淚
上面的回答可能不夠正確 有空我在寫一篇文章吧
@紅淚
理論上講如果在釋放節點的時候其他所有節點都沒有被中斷（也就是節點沒有被CANCELLED），那么就應當喚醒頭節點的下一個有效節點(頭節點是傀儡節點），也就是從head往后尋找有效繼任節點。
但是我們知道所有調用了lock()/tryLock(long time, TimeUnit unit)的線程可能會被中斷，這時候已經進入CHL隊列的節點node就會被CANCELLED，也就是會移出隊列。
而移出隊列的邏輯有點復雜，有空我單獨寫一篇文章。
簡單說就是用被移出節點node的繼任節點next替換前任有效節點的next。
用代碼描述就是java.util.concurrent.locks.AbstractQueuedSynchronizer.cancelAcquire(Node):
node=cancelled_node;
cas(node.pre.next,node,node.next);
并且將node.next指向node，也就是node沒有繼任節點了，但是不修改前任節點。
也就是說如果從后tail往前遍歷到被刪出節點node時，根據node.pre可以繼續往前移動，直到移動到head為止。
如果要想從head往后遍歷，那么代碼邏輯就是：
node = cancelled_node;
cas(node.next.pre,node,node.pre);
這兩處的邏輯差別在于，由于存在一個傀儡節點（head），因此節點node.pre總是存在的，處理起來稍微容易點。
@吳波
這段話的意思是說，tryLock(long timeout,TimeUnit unit)是定時獲取公平鎖，不會被"闖入"從而破壞公平性（指進入隊列的順序），而tryLock()卻是非公平獲取鎖方式，這回破壞公平性。
--------------
如果要想實現一個允許"闖入"破壞公平性的定時tryLock()，換句話說既想使用“闖入”提高性能，同時又想有超時特性（定時），那么可以使用下面的組合：
================
if (lock.tryLock() || lock.tryLock(timeout, unit) ) { ... }
================
補充代碼：
================
public boolean tryLock() {
return sync.nonfairTryAcquire(1);
}
--------------
public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}