@mitisky
入隊列enq 是一個CAS操作，如果加入隊列成功，會立即進行隊列自旋操作，在這個操作里面嘗試獲取鎖。
參考：
http://m.tkk7.com/xylz/archive/2010/07/07/325410.htmlacquireQueued(node,arg)
@liubey
友好的做法是子線程不拋出異常，返回不同的結果，或者將異常封裝到return對象中。父對象根據此結果/異常封裝友好的提示給界面。
@vanjayzhou
CAS的CPU原語保證A修改時，T2修改會失敗。所以T2才需要循環(huán)操作，直到成功。
JDK6以后對synchronized進行了很多優(yōu)化，而Lock基本上沒有什么可優(yōu)化的空間。在某些操作系統(tǒng)和JDK實現(xiàn)上，這種簡單的測試結果可能都不一樣。但通常情況下，高并發(fā)和長時間任務執(zhí)行上，Lock的性能比synchronized的更優(yōu)。
@徐敏
鎖數據結構的實現(xiàn)，便于程序開發(fā)。鎖也是基于CAS原子操作實現(xiàn)的，但是CAS難以使用。
@nemo
當提交一個任務時，如果需要創(chuàng)建一個線程（何時需要在下一節(jié)中探討）時，就調用線程工廠創(chuàng)建一個線程，同時將線程綁定到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
已發(fā)送
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
都已經發(fā)送了
@DarrenLee
我直接把這些都刪掉了，怪不得沒看到，太惡心了~~~
@dizzyangel
@libratears
@麒程
@sam
可以繼續(xù)使用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
既然是非線程安全的代碼，必然需要同步，這樣多線程執(zhí)行和單線程沒有分別。改寫代碼為線程安全才是正確的道理。
實在沒有辦法，應該降低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
多謝各位的厚愛，由于現(xiàn)在的破解都是無限制版，太坑人家了，畢竟人家一個團隊為此付出了很大的努力。
我爭取盡快出一個時間限制版，這樣能夠在短時間保護一下人家的利益。
@imxylz
@紅淚
上面的回答可能不夠正確 有空我在寫一篇文章吧
@紅淚
理論上講如果在釋放節(jié)點的時候其他所有節(jié)點都沒有被中斷（也就是節(jié)點沒有被CANCELLED），那么就應當喚醒頭節(jié)點的下一個有效節(jié)點(頭節(jié)點是傀儡節(jié)點），也就是從head往后尋找有效繼任節(jié)點。
但是我們知道所有調用了lock()/tryLock(long time, TimeUnit unit)的線程可能會被中斷，這時候已經進入CHL隊列的節(jié)點node就會被CANCELLED，也就是會移出隊列。
而移出隊列的邏輯有點復雜，有空我單獨寫一篇文章。
簡單說就是用被移出節(jié)點node的繼任節(jié)點next替換前任有效節(jié)點的next。
用代碼描述就是java.util.concurrent.locks.AbstractQueuedSynchronizer.cancelAcquire(Node):
node=cancelled_node;
cas(node.pre.next,node,node.next);
并且將node.next指向node，也就是node沒有繼任節(jié)點了，但是不修改前任節(jié)點。
也就是說如果從后tail往前遍歷到被刪出節(jié)點node時，根據node.pre可以繼續(xù)往前移動，直到移動到head為止。
如果要想從head往后遍歷，那么代碼邏輯就是：
node = cancelled_node;
cas(node.next.pre,node,node.pre);
這兩處的邏輯差別在于，由于存在一個傀儡節(jié)點（head），因此節(jié)點node.pre總是存在的，處理起來稍微容易點。
@吳波
這段話的意思是說，tryLock(long timeout,TimeUnit unit)是定時獲取公平鎖，不會被"闖入"從而破壞公平性（指進入隊列的順序），而tryLock()卻是非公平獲取鎖方式，這回破壞公平性。
--------------
如果要想實現(xiàn)一個允許"闖入"破壞公平性的定時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));
}