@mitisky
入队列enq 是一个CAS操作，如果加入队列成功，会立即进行队列自旋操作，在这个操作里面尝试获取锁。
参考：
http://www.blogjava.net/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://www.blogjava.net/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));
}