高性能ASP.NET站點(diǎn)構(gòu)建之托管資源優(yōu)化
高性能ASP.NET站點(diǎn)構(gòu)建系列文章目錄
- 高性能ASP.NET站點(diǎn)構(gòu)建之開篇
- 高性能ASP.NET站點(diǎn)構(gòu)建之剖析頁(yè)面的處理過程
- 高性能ASP.NET站點(diǎn)構(gòu)建之優(yōu)化HTTP請(qǐng)求
- 高性能ASP.NET站點(diǎn)構(gòu)建之細(xì)節(jié)決定成敗
- 高性能ASP.NET站點(diǎn)構(gòu)建之性能調(diào)優(yōu)綜述
- 高性能ASP.NET站點(diǎn)構(gòu)建之識(shí)別性能瓶頸
- 高性能ASP.NET站點(diǎn)構(gòu)建之簡(jiǎn)單的優(yōu)化措施
- ASP.NET站點(diǎn)構(gòu)建之減少不必要的請(qǐng)求
- 高性能ASP.NET站點(diǎn)構(gòu)建之托管資源優(yōu)化
- 高性能ASP.NET站點(diǎn)構(gòu)建之監(jiān)測(cè)CLR性能
前言：本章主要詳細(xì)的講述如何因內(nèi)存問題而導(dǎo)致的性能問題，很多的時(shí)候都是深入.NET內(nèi)核進(jìn)行分析，然后給出解決方案，同時(shí)，本系列的其他文章，也爭(zhēng)取做到：深入淺出。
本篇是為后面的做個(gè)鋪墊，而且比較的精彩。只有真正的理解了本篇，后面才可以順利的走下去。
本篇的議題如下：
內(nèi)存問題概述(前篇)
托管資源優(yōu)化（前篇）
對(duì)象的生命周期（前篇）
對(duì)象的”代“（前篇）
大對(duì)象堆(LOH) （前篇）
CLR計(jì)數(shù)器的使用（前篇）
非托管資源優(yōu)化
Session會(huì)話的優(yōu)化
內(nèi)存問題概述
和CPU一樣，內(nèi)存也是一個(gè)直接影響服務(wù)端性能的重要的硬件資源。
一般來說，如果服務(wù)端內(nèi)存不足，從導(dǎo)致以下兩個(gè)問題產(chǎn)生：
1. 導(dǎo)致服務(wù)端把一些原本要寫到內(nèi)存中的數(shù)據(jù)，寫到硬盤上面。這樣不僅僅加大了CPU和磁盤的I/O操作，同時(shí)也延長(zhǎng)了讀取這些數(shù)據(jù)的時(shí)間。
2. 阻止了一些緩存策略的使用。
對(duì)于內(nèi)存不足，一直最快最直接的方式就是去買內(nèi)存條加在服務(wù)器上面。但是這樣存在一個(gè)隱患的問題就是：如果加了新的內(nèi)存之后，服務(wù)端又面臨內(nèi)存不足的問題，我們不可能無止境的加內(nèi)存條，那么我們就必須從站點(diǎn)本身來解決這個(gè)問題，例如從服務(wù)端的配置，對(duì)站點(diǎn)的代碼進(jìn)行分析，優(yōu)化。
托管資源優(yōu)化
對(duì)于托管資源，相信大家并不陌生了，簡(jiǎn)單的說就是：在C#的托管堆上面創(chuàng)建的資源，或者說通過new產(chǎn)生的對(duì)象。
在深入講解之前，我們首先來看看”對(duì)象的生命周期”
對(duì)象的生命周期
當(dāng)我們用new關(guān)鍵字創(chuàng)建了一個(gè)對(duì)象的時(shí)候，這個(gè)對(duì)象就被分配到CRL托管堆上面。這個(gè)托管堆是在內(nèi)存中的。而且這個(gè)分配對(duì)象空間的速度是非常的快的，因?yàn)槊看味际窃谕泄芏训淖詈竺鎰澇鲆欢ǖ目臻g來給這個(gè)對(duì)象，不用去堆上面需找合適大小的空間。
如果當(dāng)托管堆準(zhǔn)備為一個(gè)對(duì)象分配空間的時(shí)候，發(fā)現(xiàn)托管堆上面的空間太小了，不足以分配給這個(gè)新的對(duì)象，那么CLR就開始運(yùn)行垃圾回收機(jī)制了。我們知道：垃圾回收機(jī)制會(huì)把那些在托管堆上面沒有了引用指向的那些對(duì)象都清理掉，同時(shí)也會(huì)把托管堆上面現(xiàn)存的對(duì)象進(jìn)行壓縮。
但是有一點(diǎn)需要清楚：如果此時(shí)進(jìn)行了垃圾回收的時(shí)候，清除了一些沒有用的對(duì)象，但是只有在下一次來回收進(jìn)行的時(shí)候，上次垃圾回收清除的對(duì)象才真正的從內(nèi)存中消除(此時(shí)，還有一些“對(duì)象復(fù)蘇“等話題就不在贅述)。
下面就來講述一些垃圾回收的話題。
對(duì)象的“代”
在CLR進(jìn)行垃圾回收的時(shí)候，垃圾回收器回去托管堆上面去檢查對(duì)象是否可以被回收，這個(gè)檢查過程是非常消耗資源的。為了避免每次垃圾回收都要便利托管堆上面的所有對(duì)象，CLR給把托管堆上面的對(duì)象用”代”來劃分，例如，第一代，第二代。然后每次便利掃描托管堆的時(shí)候，就去掃描某一個(gè)”代”中的對(duì)象，這樣性能就好點(diǎn)。
在托管堆上面，可以把對(duì)象分為三個(gè)”代”:0代，1代，2代，僅此這三個(gè)代。每個(gè)對(duì)象都是從0代開始的。一個(gè)對(duì)象每經(jīng)歷一次垃圾回收，并且這個(gè)對(duì)象還在使用中，那么這個(gè)對(duì)象的“代“就會(huì)增加1代。例如，如果在0代的對(duì)象，經(jīng)歷了一次垃圾回收之后，他的代就是1代，如果是1代的對(duì)象，最后就會(huì)變?yōu)?代。如果對(duì)象本身已經(jīng)是2代了，不管經(jīng)歷多少次垃圾回收(如果對(duì)象一直在使用)，那么這個(gè)對(duì)象還是2代。
在CLR垃圾回收中有句話要記得:” ’代’數(shù)越大，被回收的可能性就越小”。而且一些性能優(yōu)化就是根據(jù)這個(gè)進(jìn)行的。
每次CLR在進(jìn)行垃圾回收的時(shí)候，都會(huì)優(yōu)先的去掃描第0代的對(duì)象，所以，一些新的，臨時(shí)使用的對(duì)象可以被立刻的清除。相比而言，垃圾回收器掃描第1代對(duì)象的頻率就沒有第0代強(qiáng)，掃描第2代對(duì)象的頻率就更低了。所以說：對(duì)象存活的時(shí)間越長(zhǎng)，就越難被回收，而且一直占據(jù)CLR的內(nèi)存資源。
還有有點(diǎn)需要注意的就是：如果CLR決定要掃描了第1代了，同時(shí)也用掃描第0代的對(duì)象，同時(shí)如果，CLR掃描第2代對(duì)象，那么第0代，第1代對(duì)象都會(huì)被掃描。
所以，從這里可以得出：我們盡量避免把原本需要立刻回收的的對(duì)象變?yōu)殚L(zhǎng)期存活的對(duì)象。通俗點(diǎn)說就是：如果一個(gè)對(duì)象本來已經(jīng)存活在0代的，然后用完就回收的，我們不要讓這個(gè)對(duì)象一直存活到第1代，甚至第2代。在編程上面基本就是這樣的實(shí)現(xiàn)思路：盡可能晚的實(shí)例化對(duì)象，盡可能早的釋放對(duì)象。
大對(duì)象堆(Large Objecet Heap)
我們之前講述了”堆”的一些話題，CLR除了上面的一般的堆(一般的new對(duì)象分配空間的那個(gè)堆)，CLR中還存在另外的一個(gè)堆：專門用來放置那些大于了85k的對(duì)象的堆，大對(duì)象堆。
如果new一個(gè)對(duì)象的時(shí)候，這個(gè)對(duì)象的大小超過了85k，那么CLR就會(huì)把這個(gè)對(duì)象放在LOH上面。如果此時(shí)LOH的空間不足了，那么CLR就會(huì)啟動(dòng)垃圾回收器去掃描LOH堆和那個(gè)一般堆上面的第2代對(duì)象，我們之前說過，如果掃描第2代對(duì)象，就同時(shí)掃描第1代，第0代，那么實(shí)際相當(dāng)于掃描了整個(gè)托管堆，性能影響可想而知。
而且不想之前那個(gè)一般堆，在LOH上面的對(duì)象被垃圾回收器回收之后，上面的大對(duì)象是不會(huì)被壓縮的，那么LOH這個(gè)堆上面就可能存在一些”空間碎片”，然后分配新的大對(duì)象的時(shí)候，就要找空間，甚至進(jìn)行碎片的整理，大家可以聯(lián)想一下我們電腦的磁盤碎片整理。
原文鏈接：http://www.cnblogs.com/yanyangtian/archive/2011/02/17/1956768.html
【編輯推薦】
- 高性能ASP.NET站點(diǎn)構(gòu)建之開篇
- 高性能ASP.NET站點(diǎn)構(gòu)建之剖析頁(yè)面的處理過程
- 高性能ASP.NET站點(diǎn)構(gòu)建之優(yōu)化HTTP請(qǐng)求
- 高性能ASP.NET站點(diǎn)構(gòu)建之細(xì)節(jié)決定成敗
- 高性能ASP.NET站點(diǎn)構(gòu)建之性能調(diào)優(yōu)綜述
- 高性能ASP.NET站點(diǎn)構(gòu)建之識(shí)別性能瓶頸
- 高性能ASP.NET站點(diǎn)構(gòu)建之簡(jiǎn)單的優(yōu)化措施
