【原創】建構高性能ASP.NET站點 第七章 如何解決記憶體的問題(前篇)—托管資源優化—垃圾回收機制深度剖析

建構高性能ASP.NET站點 第七章 如何解決記憶體的問題(前篇)—托管資源優化—垃圾回收機制剖析

    前言：本章主要詳細的講述如何因記憶體問題而導緻的性能問題，很多的時候都是深入.NET核心進行分析，然後給出解決方案，同時，本系列的其他文章，也争取做到：深入淺出。

   本篇是為後面的做個鋪墊，而且比較的精彩。隻有真正的了解了本篇，後面才可以順利的走下去。

本篇的議題如下： 記憶體問題概述(前篇) 托管資源優化（前篇）          對象的生命周期（前篇）          對象的”代“（前篇）          大對象堆(LOH) （前篇）          CLR計數器的使用         （前篇）          CLR Profiler的使用（中篇）          垃圾回收器的不同版本（中篇）          對象使用注意事項（中篇）          常用優化措施（後篇） 非托管資源優化 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這個堆上面就可能存在一些”空間碎片”，然後配置設定新的大對象的時候，就要找空間，甚至進行碎片的整理，大家可以聯想一下我們電腦的磁盤碎片整理。

OK，今天就講到這裡，理論有點多，但是都是基本要清楚和掌握的，希望多多了解。