置頂隨筆 #
2013年11月5日 #
2013年10月16日 #
2013年10月13日 #
2013年10月8日 #
2013年9月22日 #
2013年9月15日 #
2013年9月11日 #
2013年8月17日 #
2013年8月5日 #
2013年2月24日 #
2012年12月26日 #
2012年9月25日 #
2012年6月26日 #
2012年6月7日 #
2012年5月27日 #
2012年5月22日 #
2012年5月11日 #
2012年5月10日 #
2012年4月12日 #
2012年3月28日 #
2012年3月15日 #
2012年3月9日 #
2012年2月29日 #
2012年2月16日 #
2012年2月8日 #
2012年1月29日 #
2011年12月31日 #
2011年12月30日 #
2011年12月29日 #
并發最常見用于線程池,顯然使用線程池可以有效的提高吞吐量。
最常見、比較復雜一個場景是Web容器的線程池。Web容器使用線程池同步或者異步處理HTTP請求,同時這也可以有效的復用HTTP連接,降低資源申請的開銷。通常我們認為HTTP請求時非常昂貴的,并且也是比較耗費資源和性能的,所以線程池在這里就扮演了非常重要的角色。
在線程池的章節中非常詳細的討論了線程池的原理和使用,同時也提到了,線程池的配置和參數對性能的影響是巨大的。不盡如此,受限于資源(機器的性能、網絡的帶寬等等)、依賴的服務,客戶端的響應速度等,線程池的威力也不會一直增長。達到了線程池的瓶頸后,性能和吞吐量都會大幅度降低。
一直增加機器的性能或者增大線程的個數,并不一定能有效的提高吞吐量。高并發的情況下,機器的負載會大幅提升,這時候機器的穩定性、服務的可靠性都會下降。
盡管如此,線程池依然是提高吞吐量的一個有效措施,配合合適的參數能夠有效的充分利用資源,提高資源的利用率。 閱讀全文
前面談了很多并發的特性和工具,但是大部分都是和鎖有關的。我們使用鎖來保證線程安全,但是這也會引起一些問題。
鎖順序死鎖(lock-ordering deadlock):多個線程試圖通過不同的順序獲得多個相同的資源,則發生的循環鎖依賴現象。
動態的鎖順序死鎖(Dynamic Lock Order Deadlocks):多個線程通過傳遞不同的鎖造成的鎖順序死鎖問題。
資源死鎖(Resource Deadlocks):線程間相互等待對方持有的鎖,并且誰都不會釋放自己持有的鎖發生的死鎖。也就是說當現場持有和等待的目標成為資源,就有可能發生此死鎖。這和鎖順序死鎖不一樣的地方是,競爭的資源之間并沒有嚴格先后順序,僅僅是相互依賴而已。 閱讀全文
2011年12月6日 #
非常令人吃驚的是C++語言依然不夠堅挺,由于Windows 7/Windows 8的發力,C#很快就會搶占C++的市場,估計很快就會將C++從前三名中擠下去。
iPhone/iPad的熱銷讓Object C繼續火熱,前十的位置還是可以持續很久的,這一點毋庸置疑。移動設備開發的高端人才現在是高薪難求,如果有時間我也要繼續關注下。 閱讀全文
2011年12月5日 #
Session失效問題
通常客戶端主動關閉連接認為是一次session失效。另外也有可能因為其它未知原因,例如網絡超時導致的session失效問題。在服務端看來,無法區分session失效是何種情況,一次一旦發生session失效,一定時間后就會將session持有的所有watcher以及瞬時節點刪除。
而對于Zookeeper客戶端而言,一旦發生失效不知道是否該重連,這涉及到watcher和瞬時節點問題,因此Zookeeper客戶端認為,一旦發生了seesion失效,那么就認為客戶端死掉了。從而所有操作都不能夠進行。參考 How should I handle SESSION 閱讀全文
2011年11月21日 #
有人說Redis的作者是一個勤奮的人,深表同意!
本來升級是為了增加批量操作從而提高性能,沒想到內存占用節省了很多。
對于32位的操作系統而言,節省內存62%,對于64位操作系統而言節省73%。非常可觀。 閱讀全文
2011年10月10日 #
2011年7月21日 #
2011年7月12日 #
2011年6月17日 #
2011年6月12日 #