xylz,imxylz

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

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

12 2011 档案

posted @ 2011-12-31 14:13 imxylz 阅读(6247) | 评论 (5)  编辑

posted @ 2011-12-30 17:25 imxylz 阅读(5563) | 评论 (0)  编辑

     摘要: 线程池

并发最常见用于线程池,显然使用线程池可以有效的提高吞吐量。
最常见、比较复杂一个场景是Web容器的线程池。Web容器使用线程池同步或者异步处理HTTP请求,同时这也可以有效的复用HTTP连接,降低资源申请的开销。通常我们认为HTTP请求时非常昂贵的,并且也是比较耗费资源和性能的,所以线程池在这里就扮演了非常重要的角色。
在线程池的章节中非常详细的讨论了线程池的原理和使用,同时也提到了,线程池的配置和参数对性能的影响是巨大的。不尽如此,受限于资源(机器的性能、网络的带宽等等)、依赖的服务,客户端的响应速度等,线程池的威力也不会一直增长。达到了线程池的瓶颈后,性能和吞吐量都会大幅度降低。
一直增加机器的性能或者增大线程的个数,并不一定能有效的提高吞吐量。高并发的情况下,机器的负载会大幅提升,这时候机器的稳定性、服务的可靠性都会下降。
尽管如此,线程池依然是提高吞吐量的一个有效措施,配合合适的参数能够有效的充分利用资源,提高资源的利用率。  阅读全文
posted @ 2011-12-29 16:31 imxylz 阅读(6456) | 评论 (0)  编辑

     摘要: 死锁与活跃度

前面谈了很多并发的特性和工具,但是大部分都是和锁有关的。我们使用锁来保证线程安全,但是这也会引起一些问题。
锁顺序死锁(lock-ordering deadlock):多个线程试图通过不同的顺序获得多个相同的资源,则发生的循环锁依赖现象。
动态的锁顺序死锁(Dynamic Lock Order Deadlocks):多个线程通过传递不同的锁造成的锁顺序死锁问题。
资源死锁(Resource Deadlocks):线程间相互等待对方持有的锁,并且谁都不会释放自己持有的锁发生的死锁。也就是说当现场持有和等待的目标成为资源,就有可能发生此死锁。这和锁顺序死锁不一样的地方是,竞争的资源之间并没有严格先后顺序,仅仅是相互依赖而已。  阅读全文
posted @ 2011-12-29 14:04 imxylz 阅读(6681) | 评论 (2)  编辑

     摘要: 刚看到这个月的编程语言排行榜,很显然java的霸主地位很快就会在发达国家被挤掉,C语言依然是王者(想想上个月自己买的两个C语言的书,冷汗直流)。看来我迟早要回归C,这才是真正的王道。



非常令人吃惊的是C++语言依然不够坚挺,由于Windows 7/Windows 8的发力,C#很快就会抢占C++的市场,估计很快就会将C++从前三名中挤下去。



iPhone/iPad的热销让Object C继续火热,前十的位置还是可以持续很久的,这一点毋庸置疑。移动设备开发的高端人才现在是高薪难求,如果有时间我也要继续关注下。  阅读全文
posted @ 2011-12-06 11:25 imxylz 阅读(4042) | 评论 (8)  编辑

     摘要: Zookeeper客户端和服务端维持一个长连接,每隔10s向服务端发送一个心跳,服务端返回客户端一个响应。这就是一个Session连接,拥有全局唯一的session id。Session连接通常是一直有效,如果因为网络原因断开了连接,客户端会使用相同的session id进行重连。由于服务端保留了session的各种状态,尤其是各种瞬时节点是否删除依赖于session是否失效。
Session失效问题

通常客户端主动关闭连接认为是一次session失效。另外也有可能因为其它未知原因,例如网络超时导致的session失效问题。在服务端看来,无法区分session失效是何种情况,一次一旦发生session失效,一定时间后就会将session持有的所有watcher以及瞬时节点删除。
而对于Zookeeper客户端而言,一旦发生失效不知道是否该重连,这涉及到watcher和瞬时节点问题,因此Zookeeper客户端认为,一旦发生了seesion失效,那么就认为客户端死掉了。从而所有操作都不能够进行。参考 How should I handle SESSION  阅读全文
posted @ 2011-12-05 13:57 imxylz 阅读(20655) | 评论 (8)  编辑


©2009-2014 IMXYLZ