其他

下文是轉貼於http://www.javadby.com/yuyanjichu/20080322/5220.html。因為這幾天壓力測試，然後再重溫GC的時候，覺得這片文章寫得比較詳細，對於去看GC print有一些協助。轉貼一下。 調整JVM GC(Garbage

 在傳統的軟體開發模式中，系統類比運行一般都只發生在軟體實現以後，很少有人會在需求和設計階段做這個事情。這其實是國內大部分大型軟體系統開發失敗，或者開發成功後使用者卻不買帳的原因。這個經驗其實來之於我剛工作不久的一個ERP項目，整個ERP項目團隊才4-5個人，由於第一次做這麼大的項目，我們比較謹慎，

    記得在我前一陣子的blog中寫了關於jdk1.5的pool的記憶體溢出問題，這次乘著新的memcache用戶端的使用，做了一次全面的壓力測試。jdk採用1.5的壓力測試結果壓了一個周末回來就無法響應了，看了看它的GC輸出：全都是[Full GC [Tenured: 786431K->786431K(786432K), 3.4802480 secs] 1022399K->1022399K(1022400K), [Perm : 36711K->36711K(98304K)]

    昨天集團架構委員會（虛擬組織）作了第二次交流，各個子公司都說了當前的一些進度，問題和想法，我也大致講了一下阿里軟體的服務整合平台的一些進展和自己的一些思考，這裡先貼一下PPT的圖片，後面想整理以下關於當前Open API的一些想法以及對Open API Framework的一些思路。                     

Open API分析、實踐和思索Author：文初Email：wenchu.cenwc@alibaba-inc.comBlog：http://blog.csdn.net/cenwenchu79 一.  Open API 的介紹... 2Open API的發展... 2Open API的形態... 2Open API的類型... 3Open API互動的資料格式... 4當前國外的Open API使用狀況... 4二． Open API的實踐... 5兩類基礎授權控制...

    今天，有一個使用我最佳化的Memcached cache Client給我發了郵件問到一個參數的作用，覺得還是比較重要的一個參數，因此也說一下，同時也在這裡說一下，當前最佳化過的用戶端已經作了幾次小的升級，修複了一些邊界資料的問題，大家如果在使用的話，最好能夠升級。（http://code.google.com/p/memcache-client-forjava/）   郵件如下：   你好：<socketpool name="pool0" failover="true"

    下周一應該是我今年最後一次參加內部培訓了,所要講的內容也是我這大半年來都在專註的技術:Open API&SIP。由於文章要在程式員1月刊發表，因此文章暫時不能放在Blog上，不過下周一的培訓PPT還是可以分享一下的。有興趣的集團的同學也可以來阿里軟體聽。同時也很高興的看到在csdn的blog在年底衝過了10w，希望明年有更多的分享能夠貢獻出來^_^    csdn

最近在做系統架構的時候，一個命令需要同時在多個分布節點上執行命令，但主處理又必須等所有節點執行回來後再繼續處理，因此研究了一下多線程，現分享如下：1）第1種方法，微軟提供的標準教程:利用 ManualResetEvent和WaitHandle.WaitAll:public class Fibonacci { public Fibonacci(int n, ManualResetEvent doneEvent) { _n = n;

    前幾天，看了白鴉的“一匹更快的馬”，感受最深的一點就是：很多時候經驗就給自己就地畫了一個圈，限制了自己的思維方式，扼殺了創新的萌芽。從開發人員，到架構設計實現，到架構設計，豐富的經驗積累是每個程式員的財富，但是如何使用好經驗，在什麼時候用經驗，正式這筆財富價值最大化，再次積累的關鍵。      就程式開發三個方面簡單說一下經驗使用的想法：      需求分析：站在使用者的角度看問題，做一個普通人（拋開技術經驗）   設計：     

命題：從N個不同元素中取K個元素形成的組合:        /// <summary>        /// 遞迴法        /// </summary>        /// <param name="n">N個不同元素</param>        /// <param name="k">取K個組合</param>        /// <param

    今天組裡的同學和我談起local cache的一點需求，希望考慮在效能和業務上找到平衡點應該怎麼考慮實現。下午給他的意見可能還是有點問題，回家稍微整理了一下，說出來也可以激發大家的討論，覺得現在local cache + 遠端cache是提高效能的必備，所以如何做好local cache 很有講究。   

引問：NIO在服務端的應用已經被廣為熟悉，但是在用戶端的使用，其實給予的指導並不多。同時在我看來，NIO在用戶端使用就是原來的長串連模式加上事件驅動的架構，而相對於短串連池模式來說，效能是否真的在任何環境都那麼突出，其實不然。 最近正好要最佳化TB的Cache用戶端，原始代碼是用NIO寫的，但是效率不高，效能也一般，因此反而拖累了服務端的表現，在整個最佳化過程中，看了NIO2，也就是JDK7中比較突出的AIO，同時也經過反覆最佳化和測試，其中對於NIO應用到用戶端來談一下自己的一些收穫。傳統IO

    下午在談交易類服務的時候，除了認證做數位簽章以外，也談到了重放攻擊的問題。    對於重放攻擊可以通過序號的方式來判斷。    序號從頒發角度分成：1.服務調用者自身頒發。2.服務提供者頒發。    序號產生方式分成兩類：1.不重複，隨機頒發。2.遞增。3.時間戳記。     

一個開發人員的疑問：應用程式會調用TOP的API去執行任務，首先根據單個任務執行時間很長，其次在使用者量增加的時候線程並發量很大，出現串連重設等網路問題。回答：1.合理切割任務，將任務粒度放小，減小事務時間，提高事務執行成功率，降低復原代價。2.合并任務中重複的內容，在時間間隔容許的範圍內，減少可能重複的操作。3.看是否有大量操作介面，減少單個迴圈調用次數。4.控制背景工作執行緒池線程個數，根據實際效能和對方伺服器處理能力設定並行任務個數。第四點在說明一下：線程並發開的越多未必成功率越高：首先本

Silverlight4的屬性綁定支援索引器，利用這個特性就可以實現VM對V提供更為方便的支援，而且對於基本類型的字典還可以穿越WFC RIA服務，對於DataTable之類的動態資料，就可以利用這個特性不僅可以穿越服務，還可以動態綁定到Silverlight用戶端.動態實體：public class DynamicEntity{      Dictionary<string,string> Fields{get;set} //欄位名-Caption對     

    前一陣子配合一個ISV一直在查訪問TOP服務鏈結接被重設的問題，當時認為是SDK的問題，因此我就將SDK的資料連結層代碼單獨剝離出來給ISV測試，沒有發現連結重設的問題。在加上部分業務代碼以後，有出現服務重設，但是機率很低。今天ISV同學給我發來了修改後的代碼（重設情況降低），這種修改還是有道理的，因此後續配合會升級SDK，這裡也分享一下。（當時也考慮過這方面的問題，但是看了實現代碼覺得機率不大，但是可能也就是這點機率在網路或者服務品質差的時候會被放大）            .....

1）由於以前的函數求值逾時，函數求值被禁用。必須繼續執行才能重新啟用函數求值：這是因為調試時會自動對Local/Watch等視窗裡面（或滑鼠停留所在）的變數求值，為了防止使用者寫的程式錯誤（比如死迴圈），系統有一個逾時限制，如果某個屬性的get中做了很複雜的操作（而不是簡單地返回一個私人變數的話），就有可能超過這個時間限制（如果strPage很大的話，你的正則運算就很可能會逾時）。可以禁用自動求值的功能： 工具 -> 選項 -> 調試 -> 常規 ->

    非虛模式的是將調用介面與實際執行函數分離，調用介面不支援繼承(沒有多態功能),而將實現多態的功能交給具體的保護性執行函數，這樣就使得調用介面統一，同時不損失多態的好處。具體做法如下：    /// <summary>    /// 基類    /// </summary>    public class Base    {        /// <summary>        /// 對外公布的介面，注意這裡不採用虛方法，主要是為了控制統一調用入口。

計數排序利用的是數組的隨機訪問特性，將要排序的數k轉換成數組的下標K，該數組中以k為下標的值A[k]代表這個數K的個數。這種排序非常快，但應用條件比較苛刻。主要受需要排序的序列規模（n),序列最大值(max(n))影響，如果max(n)過大，演算法空間複雜度比較高，也是該演算法的一個制約因素。下面是兩種方式實現:1) 第一種方式速度比第2種快，但沒有穩定性，而且不能用於基數計數排序。private void CountSort(int[] A)        {            List&