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