久久婷婷蜜乳一本欲蜜臀 ,色婷婷综合久久久久中文一区二区 ,亚洲人成在线观看网站高清

�U�程重命名（Netty�Q�和设计模式Decorator

steven.cui — Sat, 16 Jun 2012 14:32:00 GMT

java的多�U�程Thread�c�L��供了setName�Ҏ(gu��)��或者通过构造器传入name�Q�来指定�U�程的名�U��?/p>

�q�些旉��在开源方面看到Netty�Q�观察到Netty的重命名�U�程的策略类�Q?/p>

ThreadNameDeterminer。这个接口有两个�{�略�Q�一个是使用PROPOSED�Q�徏议名�U�ͼ��Q�还有个是CURRENT�Q�当前名�U�ͼ�

当前名称的策略是未实现的�Q�可能�ؓ(f��)以后扩展考虑吧�?/p>

另外��是ThreadRenamingRunnable�q�个�c�，�q�个�c�里面构建函��C��入Runnable接口�Q�和proposed��名称�?/p>

�׃��本��nThreadRenamingRunnable也是实现Runnable�cȝ��Q�所以你在自�׃��务逻辑�U�还是照样实现Runnable接口来写逻辑�Q�完全对业务代码没有侵入�?/p>

代码中大概是�q�样的情况：(x��)

public run() {
     //�Ҏ(gu��)��规则把线�E�名字进行修�?/span>
     try {
          runnable.run(); // 调用传入接口的run�Ҏ(gu��)��
     } finally {
          if (renamed)
               // 恢复之前的名�?/span>
     }
}

只需要在构徏的你的Runnable的时候，重新包装一下即可：(x��)

new ThreadRenamingRunnable(new OioWorker(acceptedChannel),

"Old I/O server worker (parentId: " + channel.getId() + ", " + channel + ')'));

�q�样的Decorator模式�Q�重新将Runnable接口�q�行�?#8220;装饰”�Q��其具备了�U�程名称的功能�?/p>

Runnable接口�q�是原来的接口，对run�Ҏ(gu��)��的再�ơ封装��其具备了另外一��功能，�q�就是Decorator模式的精华所在�?/p>

steven.cui 2012-06-16 22:32 发表评论

判断一个数是否�?的n�ơ幂

steven.cui — Sat, 16 Jun 2012 14:26:00 GMT

判断一个数是否�?的n�ơ幂

�c�M��q�样的数�?/p>

1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 …

if ((n & -n) == n)

…

1 public class Is2Power {
2      public static void main(String[] args) {
3           for (int i = 0;i <= 1024; i++) {
4                if ((i & -i) == i)
5                     System.out.println(Integer.toBinaryString(i) + ", " + Integer.toBinaryString(-i) + " " + i);
6           }
7      }
8 }

steven.cui 2012-06-16 22:26 发表评论

记录一个NonFairSync问题�Q�死锁问题）(LeftRighLock)

steven.cui — Sat, 16 Jun 2012 14:22:00 GMT

业务上线后，在有大量�q�发后，出现了一个线�E�完全被占用的问题，后来通过得到jvm堆栈信息(kill -3)看出来是死锁问题�?/p>

�׃��业务逻辑代码实在比较复杂�Q�此处��o(h��)掉业务代码把�U�程竞争关系展示出来�Q?/p>

1�U�程———>获得A�?#8212;——>获得B�?#8212;——>释放B�?#8212;———>释放A�?/strong>

2�U�程———>获得A�?#8212;——>释放A�?/p>
3�U�程-——————>获得B�?#8212;——>获得A�?/strong>

问题��出�?�?�U�程之间的AB锁嵌套导致死锁问题，1�U�程在没有获得B锁的时候，3�U�程开始获得B锁然后又得到了A锁，�q�时候就完全释放不了A锁了�Q�死锁��生了�?/p>
�׃��旉��关系�Q�问题是理清楚了�Q�只要删�?�U�程的A锁就可以了，当时�q�是仔细了解�q�是否删�?�U�程A锁，发现对业务A锁是没必要的。但是线�E?�?x��)不会(x��)也会(x��)像刚才一样��生线�E�死锁呢�Q�不�?x��)，因��?f��)�U�程2里�ƈ不会(x��)得到B锁�?/p>
1�U�程———>获得B�?#8212;——>释放B�?/p>
2�U�程-——————————>获得A�?#8212;———>释放A�?/p>
3�U�程———>获得B�?#8212;——>获得A�?#8212;———>释放A�?#8212;———>释放B�?/p>

问题是死锁，但暴露了两部分问题：(x��)

1.�q�早的认��p��控制好竞争关�p�，对线�E�间的竞争过早的做出了判�?/p>
2.每多设计一个锁��增加了一个竞争的因素�Q�尽量小心，一个锁��有可能是一个地��P��一不小心就可能��D��严重的问题�?/p>

�?a >《java�q�发�~�程实践�?/a>�q�本书中介绍�q�LeftRightLock�Q�详�l�了解这个问题的朋友可以��L��下这本书�?strong>�W�十�?nbsp;避免�z�跃性危�?/strong>

此书极其详细的介�l�了LeftRightLock出现的可能，有可能是因�ؓ(f��)自己�~�写�E�序的疏忽导��_(d��)��或者由于对锁的认识不��D��Q�诸多原因都能找到解释�?/p>

steven.cui 2012-06-16 22:22 发表评论

steven.cui — Tue, 15 May 2012 09:09:00 GMT

NIO的理解，请参照：(x��)http://www.goldendoc.org/category/java-nio/

Netty的一些理解，请参照：(x��)

http://www.kafka0102.com/2010/06/167.html

http://rdc.taobao.com/team/jm/archives/423

Netty的高可靠性，可�׾~�性，以及(qi��ng)效率的确让�h着�q�P��Z��么Netty�q�么快呢�Q?/p>
Netty高效的原因：(x��)

实现了多路Selector用于��d��注册�Q�线�E�数量是cpu*2�Q�reactor都是�q�么做的�Q�自己处理写事�g�Q�这个我在自己框架中也是�q�么做的�Q�nio的selector处理注册和读�Q��ƈ且也优化了wakeup�Q�Netty中的wakeup也是优化�q�的�Q�本�w�一�ơwakeup对Nio�q�不大，但是大批量�ƈ发的时候就需要进行优化处理了�Q�只有当selector堵塞的时候进行wakeup�Q�或者说需要下�ơ立刻返回的时候wakeup�?/li>
Netty在开启多路读写的时候，用的是DirectBuffer�Q��ƈ用了SoftReferrence来做�~�存优化�Q�减��传输数据的内存�U�d��和GC。还有预��数据算法，�q�个具体能不能提高有待讨�?/li>
�q�发的控�Ӟ��Z��SEDA的设计理论构建的高效事�g模型�Q�真正的异步处理�Q�吞吐量和�׾~�性都可以得到保证�?/li>

nio的实现�ƈ不复杂，但想让你的底层通讯�Q�效率，以及(qi��ng)可�׾~�性和高可靠性做好，�q�是极具挑战性的�?/p>

目前有个��目是自己写的nio�Q�但效率比�vnetty来，��了几个数量�U�，当然以本��Z��׃��力能做到目前�q�个情况�Q�还��自己满意，也用到生产环境中了，一个web game�Q�及(qi��ng)时性要求很高，一台server�Q?000人没问题。同时广播消息在10000��Z��内，当然有些优化是在业务逻辑层面的。当然比起netty的效率来讲还是差了几个数量��?/p>

除了高效�Q�Netty在扩展性方面做的不错：(x��)

丰富的decoder/encoder实现�Q�你可以��L��的��承一个类实现自己的逻辑�Q�例如游戏中�Q�直接��承FiledLengthBaseFrameDecoder卛_��?/li>
自行��d��decoder或者encoder�Q�自��q��控制事�g��向��序�Q�通过�q�个�Q�可以实��C��些协议加密解密，协议�q��o(h��)器，�l�计工具�{�等

提供很多工具�c�：(x��)Timeout的一些实玎ͼ��q�有ChannelBuffers的一些工��P��通常情况下，我们��Z��减少对Netty的依赖，�?x��)自己再��装一层，以完全达到脱��Netty的目的，都会(x��)再次��装一层ChannelBuffer�Q�这��L(f��ng)��的是不要让上层逻辑跟底层通讯有�Q何关联，降低耦合�Q�当然也在�ؓ(f��)考虑更换底层通讯而不影响上层逻辑�?/li>
提供监听底层消息的ChannelFuture�Q�例如发送完消息可以断开�q�接�{�等

可调控的通讯架构�Q�可以根据业务的吞吐量来调整�Q�Netty的各��参��C��只有socket的一些设�|�，�q�能控制事�g��顺序和吞吐量的大小�{�等�?/li>

最后，��Z��Netty我简单封装了一个web game所具备的一些GameBuffer�Q�目前比较简陋，后箋可能加入一些别的功能�?/p>

��目�?https://github.com/cuixin/XGameEnginee/

steven.cui 2012-05-15 17:09 发表评论