xylz,imxylz

关注后端架构、中间件、分布式和并发编程

   :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  111 随笔 :: 10 文章 :: 2680 评论 :: 0 Trackbacks

我的评论

@mitisky
入队列enq 是一个CAS操作,如果加入队列成功,会立即进行队列自旋操作,在这个操作里面尝试获取锁。
参考:http://www.blogjava.net/xylz/archive/2010/07/07/325410.html

acquireQueued(node,arg)
@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: Crack Xmind Pro 3.4.1 (20140212更新) imxylz 2014-02-24 20:41  
@vikiya
邮件回复吧
re: JRebel 5.5.0 Crack imxylz 2014-02-24 10:09  
@tpb
sorry for delay
re: Crack Xmind Pro 3.4.1 (20140212更新) imxylz 2014-02-24 10:07  
@newsame
@alec
@小蚂蚁
@小宝
@forexi
@ymsfd
@jeridge
已发送
re: Crack Xmind Pro 3.4.1 (20140212更新) imxylz 2014-02-24 10:05  
@ymsfd
不好,Google 吧。
re: JRebel 5.5.0 Crack imxylz 2014-02-20 13:35  
@chenhb
难道是新版本eclipse插件?
选择1:无视它,Eclipse的程序启动参数加入自定义即可
选择2:使用5.5.0版本
re: Crack Xmind Pro 3.4.1 (20140212更新) imxylz 2014-02-17 20:35  
@张云路
不知,个人没觉得有太大变化。
re: JRebel 5.5.0 Crack imxylz 2014-02-05 13:11  
@Avan
@Leo
@Miccie
@javaworld
@jaychang
@mgcnrx11
@Alex
@dada

都已经发送了
re: Crack Xmind Pro 3.4 (2013) imxylz 2013-11-15 19:29  
@DarrenLee
我直接把这些都删掉了,怪不得没看到,太恶心了~~~
re: Crack Xmind Pro 3.4 (2013) imxylz 2013-11-15 00:15  
@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: Crack Xmind Pro 3.3 (2012) imxylz 2013-02-19 14:25  
@Crystal

share the files.
re: Crack Xmind Pro 3.3 (2012) imxylz 2013-02-19 14:25  
@woodx99
share the files.
既然是非线程安全的代码,必然需要同步,这样多线程执行和单线程没有分别。改写代码为线程安全才是正确的道理。

实在没有办法,应该降低handleBusiness里面的锁的粒度,最终需要同步的逻辑越少越好。
re: Crack Xmind Pro 3.3 (2012) imxylz 2012-11-01 14:08  
@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.
re: Crack Xmind Pro 3.3 (2012) imxylz 2012-08-21 16:22  
@Newlife
我就花了三个小时,人家挺厚道的,没有使用混淆机制。大度~
re: Crack Xmind Pro 3.3 (2012) imxylz 2012-08-21 12:54  
@Newlife
@enchanter
@ygbx5174
@kafei
@footway
@sprnza
@ifans
@jack
@summer
@xmind fans
@shmily
@shen
@aoi

多谢各位的厚爱,由于现在的破解都是无限制版,太坑人家了,毕竟人家一个团队为此付出了很大的努力。

我争取尽快出一个时间限制版,这样能够在短时间保护一下人家的利益。
re: CRACK xmind 3.2.1 PRO功能 imxylz 2012-07-06 14:36  
@fangfang
已发送
re: CRACK xmind 3.2.1 PRO功能 imxylz 2012-07-05 18:11  
@VIVI
已发送
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));
}

©2009-2014 IMXYLZ