<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    當(dāng)前訪問本站: hits

    yjhmily

    堅(jiān)持走自己的路……

      BlogJava :: 首頁 :: 聯(lián)系 :: 聚合  :: 管理
      100 Posts :: 8 Stories :: 353 Comments :: 0 Trackbacks

    2011年4月6日 #

    原文出處:http://space.itpub.net/133735/viewspace-710117 
    總結(jié)的不錯(cuò)!
    -------------------------------------------------------------------------------------------------
    生產(chǎn)環(huán)境最佳實(shí)踐
    1.linux 系統(tǒng):
    1】關(guān)閉文件系統(tǒng)/分區(qū)的atime 選項(xiàng)
    Vi /etc/fstab
    在對(duì)應(yīng)的分區(qū)項(xiàng)后面添加noatime ,nodiratime
    LABEL=/1 / ext3 defaults 1 1
    LABEL=/data1 /data ext4 defaults,noatime,nodiratime 1 2
    2】設(shè)置文件句柄4k+,目前該配置已經(jīng)集成到啟動(dòng)腳本中。
    Vi /etc/security/limit.conf
    * soft nproc 65536
    * hard nproc 65536
    * soft nofile 65536
    * hard nofile 65536
    3】不要使用large vm page (不要使用大內(nèi)存頁選項(xiàng))
    Linux 大內(nèi)存頁參考:http://linuxgazette.net/155/krishnakumar.html
    4】用dmesg 查看主機(jī)的信息。
    2.linux 文件系統(tǒng)的選擇:
    Mongodb 采用預(yù)分配的大文件來存儲(chǔ)數(shù)據(jù),我們推薦
    1】ext4
    2】xfs
    3.內(nèi)核版本:
    網(wǎng)絡(luò)上對(duì)2.6.33-31 以及2.6.32 的表現(xiàn)持懷疑度, 而強(qiáng)力推薦2.6.36
    4.線程堆棧的尺寸
    默認(rèn)的線程堆棧尺寸為10m ,調(diào)整為1m ,已經(jīng)集成在啟動(dòng)腳本中。
    項(xiàng)目過程中的總結(jié)與建議
    1.大小寫問題
    mongodb 是默認(rèn)區(qū)分大小寫的,但是這會(huì)不會(huì)衍生出跟mysql 一樣的問題?(mysql 區(qū)
    分大小寫,導(dǎo)致windows 與linux 下的表名,字段名不一致)。
    如果無特別用途,建議表名,字段名全部用小寫字母。
    2.盡可能的縮短字段名的長(zhǎng)度
    mongodb 的schema free 導(dǎo)致了每筆數(shù)據(jù)都要存儲(chǔ)他的key 以及屬性,這導(dǎo)致了這些數(shù)
    據(jù)的大量冗余。開發(fā)同事也許考慮到,從易讀性出發(fā)設(shè)計(jì)的key 基本比較長(zhǎng),基本都是按
    照起字面意思去設(shè)計(jì)的。這導(dǎo)致key 很長(zhǎng)。對(duì)應(yīng)的數(shù)據(jù)存儲(chǔ)占用了很大的空間。
    必要的時(shí)候,可以考慮建立一個(gè)key 與實(shí)際意義的map 表,盡量降低key 的長(zhǎng)度。
    示例定義:
    // 基本信息
    static final String _ID = "_id";
    static final String STATUS_CODE = "sc";
    // 緩沖
    static final String DATE = "date";
    static final String MAX_AGE = "age";
    // 內(nèi)容
    static final String CONTENT = "content";
    static final String CONTENT_TYPE = "ctype";
    static final String CONTENT_LENGTH = "clen";
    static final String ZIP = "zip";
    3. mongodb 單表最大索引數(shù)為64
    無索引排序的最大數(shù)據(jù)量為4M, 超過則報(bào)錯(cuò)退出。
    建議where 條件盡量落在索引字段上,排序字段需要建立索引,索引的使用原則與oracle
    mysql 一致,盡量降低索引數(shù)量,索引長(zhǎng)度。
    mongodb 的查詢每次只能用到一個(gè)索引,對(duì)數(shù)據(jù)的查詢不會(huì)“并發(fā)”執(zhí)行
    例如: db.tab.find({'id'=1,'name'=2}) 如果‘id’,‘name' 列上分別有索引
    對(duì)查詢效率提升意義不大,如果索引為('id','name') 則大幅提升效率。
    4.mongodb 添加字段
    如果添加字段且?guī)в衐efault 值,需要全部數(shù)據(jù)都要修改,這也是設(shè)計(jì)階段需要考慮的
    事情,這個(gè)問題的另外一種解法是應(yīng)用代碼里做一次判斷。
    5.測(cè)試過程的密碼問題
    對(duì)于用作數(shù)據(jù)庫(kù)使用的Mongodb,在代碼測(cè)試階段都應(yīng)加上密碼驗(yàn)證,目前上線階段基
    本都會(huì)在密碼驗(yàn)證方面出現(xiàn)問題(做緩存使用的可以不做密碼驗(yàn)證)。
    6.數(shù)據(jù)源連接方式
    使用連接池模式,盡量減少認(rèn)證帶來的性能額外消耗
    建議采用標(biāo)準(zhǔn)的uri 連接方式: mongodb://user:passwd@host:port,host:port/db
    7.Mongodb日志量
    正常情況下不需要開啟-v 日志選項(xiàng)。
    Mongodb 的-v 日志適合在開發(fā)環(huán)境的調(diào)試線上部署不建議采用這個(gè)參數(shù),目前線上
    部署的情況,-v 日志一天也會(huì)有幾個(gè)G 的日志量,去掉這個(gè)參數(shù),跟數(shù)據(jù)查詢相關(guān)的操作
    就不會(huì)記日志了,數(shù)據(jù)庫(kù)的內(nèi)部的重要操作還是會(huì)寫日志的。
    8.連接數(shù)大小的設(shè)置
    Mongodb 驅(qū)動(dòng)程序采用的連接池的方式連接到數(shù)據(jù)庫(kù),目前從觀察到的情況是應(yīng)用一
    開啟便根據(jù)變量的設(shè)置,建立全部連接,然后提供給程序使用,并且一旦其中某個(gè)連接
    到數(shù)據(jù)庫(kù)的訪問失敗,則會(huì)清空整個(gè)連接池到這臺(tái)數(shù)據(jù)庫(kù)的連接,并重新建立連接。
    而mongodb 對(duì)中斷連接的垃圾清理工作則是懶惰的被動(dòng)清理方式,如果驅(qū)動(dòng)程序端配
    置的連接數(shù)過大,一旦發(fā)生重連,則會(huì)導(dǎo)致mongo 端堆積大量的垃圾連接數(shù)據(jù),導(dǎo)致
    主機(jī)資源耗盡。
    建議: mongodb 驅(qū)動(dòng)的連接池大小的設(shè)置一般應(yīng)該控制100 以下,一般情況30-50 足
    夠支撐應(yīng)用訪問。
    9.鎖的問題
    Mongodb 對(duì)數(shù)據(jù)庫(kù)的訪問全部加鎖,如果是查詢請(qǐng)求則設(shè)置共享鎖,數(shù)據(jù)修改請(qǐng)求,
    則設(shè)置全局排他鎖,并且是實(shí)例級(jí)別的排他鎖。并且寫鎖會(huì)阻塞讀請(qǐng)求,如果長(zhǎng)時(shí)間持有
    寫鎖,會(huì)阻塞整個(gè)實(shí)例的讀請(qǐng)求。
    部署建議:
    1】一般情況下,建議不同的應(yīng)用不要合用一套示例。
    2】如果資源不滿足,需要合用,應(yīng)該具有相同屬性的應(yīng)用合用一套實(shí)例。
    例如合同mongo 的應(yīng)用都是讀多寫少,防止一臺(tái)寫多應(yīng)用阻塞讀請(qǐng)求。
    10.關(guān)于map/reduce問題
    mongodb 對(duì)map/reduce 的支持是單線程的,我們不建議在前臺(tái)使用該功能, group by
    是通過map/reduce 實(shí)現(xiàn)的,開發(fā)過程中,要慎用。
    11.安全問題
    1】Mongodb 運(yùn)行在mongodb 用戶之上,并禁止mongodb 用戶登錄
    2】使用Mongodb 自帶的認(rèn)證方法(adduser、auth)限制用戶訪問行為
    3】將Mongodb 置于內(nèi)網(wǎng)環(huán)境中
    4】Mongodb 必須暴露在外網(wǎng)環(huán)境中的時(shí)候,使用IPTABLES 等網(wǎng)絡(luò)層技術(shù)進(jìn)行防護(hù)
    5】網(wǎng)絡(luò)層面內(nèi)容為明文傳輸,可以考慮存儲(chǔ)加密文檔,應(yīng)用端,加解密。
    12.性能監(jiān)控
    Mongodb 自帶有性能數(shù)據(jù)收集系統(tǒng)
    Mongostat 實(shí)時(shí)采集數(shù)據(jù)庫(kù)的多項(xiàng)指標(biāo),提供http console 端口號(hào)為應(yīng)用端口號(hào)+1000。
    關(guān)注的主要性能指標(biāo):
    1】Faults:顯示Mongodb 每秒頁面故障的數(shù)量,這個(gè)是mongoDB 映射到虛擬地址空間,
    而不是物理內(nèi)存,這個(gè)值如果飆高的話,可能意味著機(jī)器沒有足夠的內(nèi)存來
    存儲(chǔ)數(shù)據(jù)和索引。
    2】Flushes:每秒做了多少次fsync,顯示多少次數(shù)據(jù)被刷新進(jìn)了磁盤
    3】locked:寫鎖
    4】idx miss:索引未命中比例
    5】qr | qw:讀寫鎖的請(qǐng)求隊(duì)列長(zhǎng)度。
    6】conn: 當(dāng)前已經(jīng)建立的連接數(shù)。
    其他命令:
    Db.stat()
    db.serverStatuse()
    Db.collection.stats()
    13.碎片問題
    Mongodb 數(shù)據(jù)庫(kù)如果數(shù)據(jù)修改很頻繁,會(huì)出現(xiàn)比較嚴(yán)重的空間碎片問題,表現(xiàn)在磁盤
    文件擴(kuò)張與實(shí)際數(shù)據(jù)量不相符,內(nèi)存不夠用,索引命中率低,查詢效率降低。
    碎片整理,目前我們采用的版本沒有太有效的方法。
    可以用db.repaireDatabase() 來整理數(shù)據(jù)庫(kù),這個(gè)過程非常的慢
    如果是Master-slave 模式則相當(dāng)于執(zhí)行一次主從切換,然后從新建立從庫(kù)。
    如果是replSet 架構(gòu)可以停掉數(shù)據(jù)庫(kù),然后刪除數(shù)據(jù)目錄,從新從復(fù)制復(fù)制組中全同步數(shù)據(jù),
    這個(gè)時(shí)候要考慮oplog 的尺寸。
    一個(gè)大體的步驟:
    1.】先調(diào)用rs.freeze(1200),將每個(gè)不想讓它成為primary 的機(jī)器讓它在1200 秒內(nèi)無法成為
    primary(這步也可以不做)
    2. 】將primary stepDown,不出意外新的primary 會(huì)起來.
    3. 】將原primary kill 掉.
    4. 】刪掉所有data 數(shù)據(jù)(調(diào)用repair 很慢,真不如干掉重新來)
    5. 】再重啟動(dòng)原primary 的進(jìn)程
    6. 】以此循環(huán)完成整個(gè)復(fù)制組的全部重建。
    14.系統(tǒng)備份:
    Mongodb 目前不支持在線備份,只能離線備份。
    我們采用的架構(gòu)為replSet 和Master-slave .
    基于我們目前的架構(gòu)以及數(shù)據(jù)一致性要求,我們沒有安排相關(guān)的備份系統(tǒng)。
    15.應(yīng)用代碼中Mongodb連接問題
    在有些應(yīng)用在使用Mongodb 過程中會(huì)存在以下兩個(gè)小問題:
    1. 在應(yīng)用啟動(dòng)過程中,應(yīng)用存在要求連接池中所有的連接都建立成功才讓應(yīng)用正
    常啟動(dòng),這種做法不可取,因?yàn)榇嬖诰W(wǎng)絡(luò)問題、Mongodb 拒絕連接或Mongodb 假死情況,如
    果沒加外部try catch 做防護(hù),則Resin 不斷重啟也不能正常啟動(dòng)端口。
    2.有些應(yīng)用在使用Mongodb 中連接池配置了safe=true,w=1;這種配置意味著客戶端在
    插入數(shù)據(jù)或更新數(shù)據(jù)的時(shí)候,要求mongodb 必須將所更新的數(shù)據(jù)寫入磁盤并返回更新成功
    的信息給程序。如果碰上應(yīng)用程序訪問壓力大,mongodb 就會(huì)反應(yīng)遲鈍,并會(huì)發(fā)生假死可能,
    針對(duì)此情況,需要評(píng)估數(shù)據(jù)的一致性需求,做出合適調(diào)整。我們一般建議關(guān)閉此選項(xiàng)。
    16.補(bǔ)充開發(fā)方面的一些問題
    1】skip+limit翻頁,越往后面越慢,有資料說用數(shù)組元素的分頁可以解決,目前還沒
    試過,比較靠譜的做法是,先找出上次的id,翻頁的時(shí)候不用skip:
    last_row_id = ObjectId(‘....’);
    db.activity_stream->find({_id:{$lt: last_row_id },
    user_id:20 } ).sort( {_id:-1} ).limit(10);
    2】.只有真正需要的字段才select出來
    3】.更新的某條數(shù)據(jù)的時(shí)候,先查出來再更新會(huì)減小鎖的時(shí)間
    4】.只有返回很少結(jié)果的查詢才用索引,否則會(huì)加載太多數(shù)據(jù),比沒有用索引還慢
    5】.屬性比較多的時(shí)候,建立分層的關(guān)系能夠提高查詢效率,否則每個(gè)記錄都要過一遍
    才能找到要的屬性
    17.關(guān)于硬件資源的選擇:
    虛擬機(jī)可以很好的隔離資源,并可動(dòng)態(tài)的擴(kuò)展。
    我們建議mongodb 的部署采用虛擬機(jī)的方式,每個(gè)虛擬機(jī)部署一個(gè)實(shí)例,使各節(jié)點(diǎn)分
    散在不同的物理機(jī)上,根據(jù)應(yīng)用的前期預(yù)測(cè),平衡虛擬機(jī)的之間的i/o。
    posted @ 2012-09-29 22:17 kangxm 閱讀(635) | 評(píng)論 (0)編輯 收藏

    adb shell

    # mount -oremount,rw /dev/block/mtdblock3 /system

    # pm list packages -f (列出apk和包名的對(duì)應(yīng)關(guān)系)
    # cd /system/app (APK文件所在地)
    # rm Mms.* (rom自帶的短信)
    # exit

     

    adb uninstall com.android.mms

     

    返回Success,就說明卸載成功了

     

    注意..
    刪除之前, 最好用

    1. adb pull /system/app/xxx.apk .

    復(fù)制代碼

    給備份一下, 避免出錯(cuò)(系統(tǒng)老是Force Close, 沒法用).
    出錯(cuò)后, 可以用

    1. adb push xxx.apk /system/app
    adb shell

    # mount -oremount,rw /dev/block/mtdblock3 /system

    # pm list packages -f (列出apk和包名的對(duì)應(yīng)關(guān)系)
    # cd /system/app (APK文件所在地)
    # rm Mms.* (rom自帶的短信)
    # exit

     

    adb uninstall com.android.mms

     

    返回Success,就說明卸載成功了

     

    注意..
    刪除之前, 最好用

    1. adb pull /system/app/xxx.apk .

    復(fù)制代碼

    給備份一下, 避免出錯(cuò)(系統(tǒng)老是Force Close, 沒法用).
    出錯(cuò)后, 可以用

    1. adb push xxx.apk /system/app
    posted @ 2012-08-10 17:56 kangxm 閱讀(539) | 評(píng)論 (0)編輯 收藏

    最近的機(jī)器內(nèi)存又爆滿了,出了新增機(jī)器內(nèi)存外,還應(yīng)該好好review一下我們的代碼,有很多代碼編寫過于隨意化,這些不好的習(xí)慣或?qū)Τ绦蛘Z言的不了解是應(yīng)該好好打壓打壓了。
    下面是參考網(wǎng)絡(luò)資源和總結(jié)一些在java編程中盡可能做到的一些地方
    -
    1.盡量在合適的場(chǎng)合使用單例
    使用單例可以減輕加載的負(fù)擔(dān),縮短加載的時(shí)間,提高加載的效率,但并不是所有地方都適用于單例,簡(jiǎn)單來說,單例主要適用于以下三個(gè)方面
    第一,控制資源的使用,通過線程同步來控制資源的并發(fā)訪問
    第二,控制實(shí)例的產(chǎn)生,以達(dá)到節(jié)約資源的目的
    第三,控制數(shù)據(jù)共享,在不建立直接關(guān)聯(lián)的條件下,讓多個(gè)不相關(guān)的進(jìn)程或線程之間實(shí)現(xiàn)通信
    -
    2.盡量避免隨意使用靜態(tài)變量
    要知道,當(dāng)某個(gè)對(duì)象被定義為stataic變量所引用,那么gc通常是不會(huì)回收這個(gè)對(duì)象所占有的內(nèi)存,如
    public class A{
    static B b = new B();
    }
    此時(shí)靜態(tài)變量b的生命周期與A類同步,如果A類不會(huì)卸載,那么b對(duì)象會(huì)常駐內(nèi)存,直到程序終止。
    -
    3.盡量避免過多過常的創(chuàng)建java對(duì)象
    盡量避免在經(jīng)常調(diào)用的方法,循環(huán)中new對(duì)象,由于系統(tǒng)不僅要花費(fèi)時(shí)間來創(chuàng)建對(duì)象,而且還要花時(shí)間對(duì)這些對(duì)象進(jìn)行垃圾回收和處理,在我們可以控制的范圍內(nèi),最
    大限度的重用對(duì)象,最好能用基本的數(shù)據(jù)類型或數(shù)組來替代對(duì)象。
    -
    4.盡量使用final修飾符
    帶 有final修飾符的類是不可派生的。在Java核心API中,有許多應(yīng)用final的例子,例如java.lang.String。為String類指 定final防止了使用者覆蓋length()方法。另外,如果一個(gè)類是final的,則該類所有方法都是final的。java編譯器會(huì)尋找機(jī)會(huì)內(nèi)聯(lián) (inline)所有的final方法(這和具體的編譯器實(shí)現(xiàn)有關(guān))。此舉能夠使性能平均提高50%。
    -
    5.盡量使用局部變量
    調(diào)用方法時(shí)傳遞的參數(shù)以及在調(diào)用中創(chuàng)建的臨時(shí)變量都保存在棧(Stack)中,速度較快。其他變量,如靜態(tài)變量,實(shí)例變量等,都在堆(Heap)中創(chuàng)建,速度較慢。
    -
    6.盡量處理好包裝類型和基本類型兩者的使用場(chǎng)所
    雖然包裝類型和基本類型在使用過程中是可以相互轉(zhuǎn)換,但它們兩者所產(chǎn)生的內(nèi)存區(qū)域是完全不同的,基本類型數(shù)據(jù)產(chǎn)生和處理都在棧中處理,包裝類型是對(duì)象,是在堆中產(chǎn)生實(shí)例。
    在集合類對(duì)象,有對(duì)象方面需要的處理適用包裝類型,其他的處理提倡使用基本類型。
    -
    7.慎用synchronized,盡量減小synchronize的方法
    都 知道,實(shí)現(xiàn)同步是要很大的系統(tǒng)開銷作為代價(jià)的,甚至可能造成死鎖,所以盡量避免無謂的同步控制。synchronize方法被調(diào)用時(shí),直接會(huì)把當(dāng)前對(duì)象鎖 了,在方法執(zhí)行完之前其他線程無法調(diào)用當(dāng)前對(duì)象的其他方法。所以synchronize的方法盡量小,并且應(yīng)盡量使用方法同步代替代碼塊同步。
    -
    8.盡量使用StringBuilder和StringBuffer進(jìn)行字符串連接
    這個(gè)就不多講了
    -
    9.盡量不要使用finalize方法
    實(shí)際上,將資源清理放在finalize方法中完成是非常不好的選擇,由于GC的工作量很大,尤其是回收Young代內(nèi)存時(shí),大都會(huì)引起應(yīng)用程序暫停,所以再選擇使用finalize方法進(jìn)行資源清理,會(huì)導(dǎo)致GC負(fù)擔(dān)更大,程序運(yùn)行效率更差。
    -
    10.盡量使用基本數(shù)據(jù)類型代替對(duì)象
    String str = "hello";
    上面這種方式會(huì)創(chuàng)建一個(gè)“hello”字符串,而且JVM的字符緩存池還會(huì)緩存這個(gè)字符串;
    String str = new String("hello");
    此時(shí)程序除創(chuàng)建字符串外,str所引用的String對(duì)象底層還包含一個(gè)char[]數(shù)組,這個(gè)char[]數(shù)組依次存放了h,e,l,l,o
    -
    11.單線程應(yīng)盡量使用HashMap, ArrayList
    HashTable,Vector等使用了同步機(jī)制,降低了性能。
    -
    12.盡量合理的創(chuàng)建HashMap
    當(dāng)你要?jiǎng)?chuàng)建一個(gè)比較大的hashMap時(shí),充分利用另一個(gè)構(gòu)造函數(shù)
    public HashMap(int initialCapacity, float loadFactor)
    避 免HashMap多次進(jìn)行了hash重構(gòu),擴(kuò)容是一件很耗費(fèi)性能的事,在默認(rèn)中initialCapacity只有16,而loadFactor是 0.75,需要多大的容量,你最好能準(zhǔn)確的估計(jì)你所需要的最佳大小,同樣的Hashtable,Vectors也是一樣的道理。
    -
    13.盡量減少對(duì)變量的重復(fù)計(jì)算
    for(int i=0;i<list.size();i++)
    應(yīng)該改為
    for(int i=0,len=list.size();i<len;i++)
    并且在循環(huán)中應(yīng)該避免使用復(fù)雜的表達(dá)式,在循環(huán)中,循環(huán)條件會(huì)被反復(fù)計(jì)算,如果不使用復(fù)雜表達(dá)式,而使循環(huán)條件值不變的話,程序?qū)?huì)運(yùn)行的更快。 
    -
    14.盡量避免不必要的創(chuàng)建
    A a = new A();
    if(i==1){list.add(a);}
    應(yīng)該改為
    if(i==1){
    A a = new A();
    list.add(a);}
    -
    15.盡量在finally塊中釋放資源
    程序中使用到的資源應(yīng)當(dāng)被釋放,以避免資源泄漏。這最好在finally塊中去做。不管程序執(zhí)行的結(jié)果如何,finally塊總是會(huì)執(zhí)行的,以確保資源的正確關(guān)閉。 
    -
    16.盡量使用移位來代替'a/b'的操作
    "/"是一個(gè)代價(jià)很高的操作,使用移位的操作將會(huì)更快和更有效
    int num = a / 4;
    int num = a / 8;
    應(yīng)該改為
    int num = a >> 2;
    int num = a >> 3;
    但注意的是使用移位應(yīng)添加注釋,因?yàn)橐莆徊僮鞑恢庇^,比較難理解
    -
    17.盡量使用移位來代替'a*b'的操作
    同樣的,對(duì)于'*'操作,使用移位的操作將會(huì)更快和更有效
    int num = a * 4;
    int num = a * 8;
    應(yīng)該改為
    int num = a << 2;
    int num = a << 3;
    -
    18.盡量確定StringBuffer的容量
    StringBuffer 的構(gòu)造器會(huì)創(chuàng)建一個(gè)默認(rèn)大小(通常是16)的字符數(shù)組。在使用中,如果超出這個(gè)大小,就會(huì)重新分配內(nèi)存,創(chuàng)建一個(gè)更大的數(shù)組,并將原先的數(shù)組復(fù)制過來,再 丟棄舊的數(shù)組。在大多數(shù)情況下,你可以在創(chuàng)建 StringBuffer的時(shí)候指定大小,這樣就避免了在容量不夠的時(shí)候自動(dòng)增長(zhǎng),以提高性能。 
    如:StringBuffer buffer = new StringBuffer(1000);  
    -
    19.盡量早釋放無用對(duì)象的引用
    大部分時(shí),方法局部引用變量所引用的對(duì)象 會(huì)隨著方法結(jié)束而變成垃圾,因此,大部分時(shí)候程序無需將局部,引用變量顯式設(shè)為null。
    例如:
    Public void test(){
    Object obj = new Object();
    ……
    Obj=null;
    }
    上面這個(gè)就沒必要了,隨著方法test()的執(zhí)行完成,程序中obj引用變量的作用域就結(jié)束了。但是如果是改成下面:
    Public void test(){
    Object obj = new Object();
    ……
    Obj=null;
    //執(zhí)行耗時(shí),耗內(nèi)存操作;或調(diào)用耗時(shí),耗內(nèi)存的方法
    ……
    }
    這時(shí)候就有必要將obj賦值為null,可以盡早的釋放對(duì)Object對(duì)象的引用。
    -
    20.盡量避免使用二維數(shù)組
    二維數(shù)據(jù)占用的內(nèi)存空間比一維數(shù)組多得多,大概10倍以上。
    -
    21.盡量避免使用split
    除 非是必須的,否則應(yīng)該避免使用split,split由于支持正則表達(dá)式,所以效率比較低,如果是頻繁的幾十,幾百萬的調(diào)用將會(huì)耗費(fèi)大量資源,如果確實(shí)需 要頻繁的調(diào)用split,可以考慮使用apache的StringUtils.split(string,char),頻繁split的可以緩存結(jié)果。
    -
    22.ArrayList & LinkedList
    一 個(gè)是線性表,一個(gè)是鏈表,一句話,隨機(jī)查詢盡量使用ArrayList,ArrayList優(yōu)于LinkedList,LinkedList還要移動(dòng)指 針,添加刪除的操作LinkedList優(yōu)于ArrayList,ArrayList還要移動(dòng)數(shù)據(jù),不過這是理論性分析,事實(shí)未必如此,重要的是理解好2 者得數(shù)據(jù)結(jié)構(gòu),對(duì)癥下藥。
    -
    23.盡量使用System.arraycopy ()代替通過來循環(huán)復(fù)制數(shù)組
    System.arraycopy() 要比通過循環(huán)來復(fù)制數(shù)組快的多 
    -
    24.盡量緩存經(jīng)常使用的對(duì)象
    盡可能將經(jīng)常使用的對(duì)象進(jìn)行緩存,可以使用數(shù)組,或HashMap的容器來進(jìn)行緩存,但這種方式可能導(dǎo)致系統(tǒng)占用過多的緩存,性能下降,推薦可以使用一些第三方的開源工具,如EhCache,Oscache進(jìn)行緩存,他們基本都實(shí)現(xiàn)了FIFO/FLU等緩存算法。
    -
    25.盡量避免非常大的內(nèi)存分配
    有時(shí)候問題不是由當(dāng)時(shí)的堆狀態(tài)造成的,而是因?yàn)榉峙涫≡斐傻摹7峙涞膬?nèi)存塊都必須是連續(xù)的,而隨著堆越來越滿,找到較大的連續(xù)塊越來越困難。
    -
    26.慎用異常
    當(dāng) 創(chuàng)建一個(gè)異常時(shí),需要收集一個(gè)棧跟蹤(stack track),這個(gè)棧跟蹤用于描述異常是在何處創(chuàng)建的。構(gòu)建這些棧跟蹤時(shí)需要為運(yùn)行時(shí)棧做一份快照,正是這一部分開銷很大。當(dāng)需要?jiǎng)?chuàng)建一個(gè) Exception 時(shí),JVM 不得不說:先別動(dòng),我想就您現(xiàn)在的樣子存一份快照,所以暫時(shí)停止入棧和出棧操作。棧跟蹤不只包含運(yùn)行時(shí)棧中的一兩個(gè)元素,而是包含這個(gè)棧中的每一個(gè)元素。
    如 果您創(chuàng)建一個(gè) Exception ,就得付出代價(jià)。好在捕獲異常開銷不大,因此可以使用 try-catch 將核心內(nèi)容包起來。從技術(shù)上講,您甚至可以隨意地拋出異常,而不用花費(fèi)很大的代價(jià)。招致性能損失的并不是 throw 操作——盡管在沒有預(yù)先創(chuàng)建異常的情況下就拋出異常是有點(diǎn)不尋常。真正要花代價(jià)的是創(chuàng)建異常。幸運(yùn)的是,好的編程習(xí)慣已教會(huì)我們,不應(yīng)該不管三七二十一就 拋出異常。異常是為異常的情況而設(shè)計(jì)的,使用時(shí)也應(yīng)該牢記這一原則。

    文章主要是為了拋磚引玉,希望有更多牛人的指點(diǎn)

    謝謝的 xuanyuan 的建議:
    ===================================================
    7.慎用synchronized,盡量減小synchronize的方法
    re:同意,不過文中有個(gè)地方說錯(cuò)了,使用synchronized關(guān)鍵字并不一定都是鎖定當(dāng)前對(duì)象的,要看具體的鎖是什么。如果是在方法上加的synchronized,則是以對(duì)象本身為鎖的,如果是靜態(tài)方法則鎖的粒度是類。
    ---------------
    9.盡量不要使用finalize方法
    re:同意,其實(shí)不推薦用finalize方法的根本原因在于,JVM的規(guī)范并不保證何時(shí)執(zhí)行該方法,所以用這個(gè)方法來釋放資源很不合適,有可能造成長(zhǎng)時(shí)間資源得不到釋放。
    ---------------
    16.盡量使用移位來代替'a/b'的操作;17.盡量使用移位來代替'a*b'的操作
    re:個(gè)人不太同意這兩條。這樣做確實(shí)有更好的性能,但是卻犧牲了可讀性。這兩個(gè)操作符對(duì)很多程序員來說并不直觀。我認(rèn)為在如今硬件價(jià)格不那么昂貴的情況下,略微犧牲一些性能,換來更好的可讀性和可維護(hù)性是好的選擇。
    ===================================================
    19.盡量早釋放無用對(duì)象的引用
    大部分時(shí),方法局部引用變量所引用的對(duì)象 會(huì)隨著方法結(jié)束而變成垃圾,因此,大部分時(shí)候程序無需將局部,引用變量顯式設(shè)為null。
    例如:
    Public void test(){
    Object obj = new Object();
    ……
    Obj=null;
    }
    上面這個(gè)就沒必要了,隨著方法test()的執(zhí)行完成,程序中obj引用變量的作用域就結(jié)束了。但是如果是改成下面:
    Public void test(){
    Object obj = new Object();
    ……
    Obj=null;
    //執(zhí)行耗時(shí),耗內(nèi)存操作;或調(diào)用耗時(shí),耗內(nèi)存的方法
    ……
    }
    如果Object obj = new Object(); 如果這對(duì)象并不是大對(duì)象,這有必要嗎?Obj=null;只是告訴jvm這個(gè)對(duì)象已經(jīng)成為垃圾,至于什么時(shí)候回收,還不能確定! 這可讀性也不好!
    ===================================================
    posted @ 2011-08-22 15:18 kangxm 閱讀(561) | 評(píng)論 (0)編輯 收藏

    提示/boot目錄空間不足,查了一些資料,最后把久的內(nèi)核給卸載得以解決。

    1.首先查看自己使用的內(nèi)核

    lxz@lxz-pc:~$ uname -a

    Linux lxz-pc 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:48 UTC 2011 i686 GNU/Linux


    2.然后查看自己boot目錄,選擇需要卸載的版本
    lxz@lxz-pc:~$    cd /boot
    lxz@lxz-pc:/boot$  ls -l
    總計(jì) 35125
    -rw-r--r-- 1 root root   705861 2011-01-22 06:04 abi-2.6.35-25-generic
    -rw-r--r-- 1 root root   709370 2011-03-01 23:56 abi-2.6.35-28-generic-pae
    -rw-r--r-- 1 root root   128615 2011-01-22 06:04 config-2.6.35-25-generic
    -rw-r--r-- 1 root root   129056 2011-03-01 23:56 config-2.6.35-28-generic-pae
    drwxr-xr-x 3 root root     7168 2011-03-23 10:31 grub
    -rw-r--r-- 1 root root 10761551 2011-03-04 10:49 initrd.img-2.6.35-25-generic
    -rw-r--r-- 1 root root 10741569 2011-03-23 10:18 initrd.img-2.6.35-28-generic-pae
    drwx------ 2 root root    12288 2011-01-05 04:52 lost+found
    -rw-r--r-- 1 root root   165084 2010-09-25 01:14 memtest86+.bin
    -rw-r--r-- 1 root root   167264 2010-09-25 01:14 memtest86+_multiboot.bin
    -rw-r--r-- 1 root root  1831296 2011-01-22 06:04 System.map-2.6.35-25-generic
    -rw-r--r-- 1 root root  1873873 2011-03-01 23:56 System.map-2.6.35-28-generic-pae
    -rw-r--r-- 1 root root     1192 2011-01-22 06:06 vmcoreinfo-2.6.35-25-generic
    -rw-r--r-- 1 root root     1196 2011-03-01 23:57 vmcoreinfo-2.6.35-28-generic-pae
    -rw-r--r-- 1 root root  4294672 2011-01-22 06:04 vmlinuz-2.6.35-25-generic
    -rw-r--r-- 1 root root  4428048 2011-03-01 23:56 vmlinuz-2.6.35-28-generic-pae
    上面顯示的情況中,是我已經(jīng)把linux-image-2.6.35-27-generic的結(jié)果

    3.卸載舊內(nèi)核應(yīng)該使用命令:
    lxz@lxz-pc:/boot$  sudo apt-get remove linux-image-2.6.35-27-generic

    4.查看/boot目錄:
    lxz@lxz-pc:/boot$ sudo du -m /boot           //以MB為單位顯示
    1    /boot/grub/locale
    2    /boot/grub
    1    /boot/lost+found
    36    /boot

    5.查看文件系統(tǒng)使用情況,和文件系統(tǒng)被掛在的位置:
    lxz@lxz-pc:/boot$  df  -lh
    文件系統(tǒng)            容量  已用  可用 已用%% 掛載點(diǎn)
    /dev/sda7              71G  7.7G   60G  12% /
    none                 1001M  244K 1001M   1% /dev
    none                 1007M  216K 1006M   1% /dev/shm
    none                 1007M  100K 1006M   1% /var/run
    none                 1007M     0 1007M   0% /var/lock
    /dev/sda8              92M   42M   46M  48% /boot
    posted @ 2011-04-06 12:09 kangxm 閱讀(3190) | 評(píng)論 (0)編輯 收藏

    主站蜘蛛池模板: 亚洲精品黄色视频在线观看免费资源| 全部免费毛片在线| 99视频在线免费观看| 亚洲熟妇少妇任你躁在线观看| 亚洲AV日韩AV天堂久久| 国产精品亚洲玖玖玖在线观看| 国产精品成人免费一区二区| 无码精品国产一区二区三区免费 | 黄色a级片免费看| 亚洲一级毛片视频| 久久亚洲私人国产精品vA | 2020国产精品亚洲综合网| 久久精品国产亚洲av麻豆 | 一级中文字幕免费乱码专区| 亚洲中文字幕乱码一区| 亚洲啪啪免费视频| 亚洲美女大bbbbbbbbb| 亚洲级αV无码毛片久久精品| 亚洲成a人一区二区三区| 国产精品无码一区二区三区免费| www.黄色免费网站| 黄瓜视频影院在线观看免费| 久久精品国产免费观看| 一级毛片aaaaaa免费看| 一级成人a毛片免费播放| 久久午夜伦鲁片免费无码| 香蕉免费一区二区三区| 99在线在线视频免费视频观看| 无码人妻AV免费一区二区三区 | 亚洲高清不卡视频| 亚洲老熟女@TubeumTV| 亚洲精品国产情侣av在线| 亚洲色图.com| 亚洲天堂2016| 亚洲久热无码av中文字幕| 亚洲精品乱码久久久久久V| 亚洲av无码专区在线观看下载| 色九月亚洲综合网| eeuss影院ss奇兵免费com| a级成人毛片免费视频高清| 免费高清国产视频|