記憶體分配：

1、棧區（stack）— 由編譯器自動分配釋放 ，存放區域性變數、臨時變數、引數值。其操作方式類似於資料結構中的棧。
2、堆區（heap） — 一般由程式設計師分配釋放， 若程式設計師不釋放，程式結束時可能由OS回收 。
3、全域性區（靜態區）（static）—，全域性變數和靜態變數的儲存是放在一塊的，初始化的全域性變數和靜態變數在一塊區域（.data區）， 未初始化的全域性變數和未初始化的靜態變數在相鄰的另一塊區域（.bss區）。 - 程式結束後由系統釋放。
4、文字常量區（常量區） —常量字串就是放在這裡的。 程式結束後由系統釋放
5、程式程式碼區—存放函式體的二進位制程式碼。

這其中最容易混淆的就是：常量到底存在哪？

想弄清楚這個問題，首先要明確，什麼是常量？

而我們通常說的常量包括文字常量、字串常量、數字常量和常變數，如'a'，"ab",1和 const int a。

注意！常量區既不是存放文字常量和數字常量（存放在程式碼區），也不是存放常變數（存放在堆區和棧區）的地方。常量區儲存的是字串常量，類的虛擬函式表等

程式碼區和文字常量區有時合稱為只讀區

來看一個網上很流行的經典例子：

main.cpp

  int a =2; //全域性初始化區 
  char *p1; //全域性未初始化區 
  main() 
  { 
      int b; //棧 
      char s[] = "abc"; //！！！！！！特別注意！！！！！！此處全部儲存在棧中，不存放在常量區 
      char *p2; //棧 
      char *p3 = "123456"; //123456\0在常量區，p3在棧上。 
      static int c =1； //全域性（靜態）初始化區 
     p1 = (char *)malloc(10); //堆 
     p2 = (char *)malloc(20);  //堆 
 }

堆和棧是面試被經常問的，這裡詳細講解一下

棧上的空間是自動分配自動回收的，堆則是程式設計師根據需要自己申請的空間，需要程式設計師手動釋放

記憶體分配中的棧和堆

記憶體中的堆和棧要和資料結構中的堆和棧區分開！！
堆的具體實現和作業系統有關，個人感覺記憶體中的堆還是更像連結串列

C/C++程式記憶體分配如下圖所示：

堆和棧的其它幾點不同：

1.申請後系統的響應

棧：只要棧的剩餘空間大於所申請空間，系統將為程式提供記憶體，否則將報異常提示棧溢位。

堆：首先應該知道作業系統有一個記錄空閒記憶體地址的連結串列，當系統收到程式的申請時，會遍歷該連結串列，尋找第一個空間大於所申請空間的堆結點，然後將該結點從空閒結點連結串列中刪除，並將該結點的空間分配給程式，另外，對於大多數系統，會在這塊記憶體空間中的首地址處記錄本次分配的大小，這樣，程式碼中的 delete語句才能正確的釋放本記憶體空間。另外，由於找到的堆結點的大小不一定正好等於申請的大小，系統會自動的將多餘的那部分重新放入空閒連結串列中。

也就是說堆會在申請後還要做一些後續的工作這就會引出申請效率的問題。

2.申請效率的比較

根據第0點和第1點可知。

棧：由系統自動分配，速度較快。但程式設計師是無法控制的。

堆：是由new分配的記憶體，一般速度比較慢，而且容易產生記憶體碎片,不過用起來最方便。

3.申請大小的限制

棧：在Windows下,棧是向低地址擴充套件的資料結構，是一塊連續的記憶體的區域。這句話的意思是棧頂的地址和棧的最大容量是系統預先規定好的，在 WINDOWS下，棧的大小是2M（也有的說是1M，總之是一個編譯時就確定的常數），如果申請的空間超過棧的剩餘空間時，將提示overflow。因此，能從棧獲得的空間較小。

堆：堆是向高地址擴充套件的資料結構，是不連續的記憶體區域。這是由於系統是用連結串列來儲存的空閒記憶體地址的，自然是不連續的，而連結串列的遍歷方向是由低地址向高地址。堆的大小受限於計算機系統中有效的虛擬記憶體。由此可見，堆獲得的空間比較靈活，也比較大。

4.堆和棧中的儲存內容

由於棧的大小有限，所以用子函式還是有物理意義的，而不僅僅是邏輯意義。

棧： 在函式呼叫時，第一個進棧的是主函式中函式呼叫後的下一條指令（函式呼叫語句的下一條可執行語句）的地址，然後是函式的各個引數，在大多數的C編譯器中，引數是由右往左入棧的，然後是函式中的區域性變數。注意靜態變數是不入棧的。
當本次函式呼叫結束後，區域性變數先出棧，然後是引數，最後棧頂指標指向最開始存的地址，也就是主函式中的下一條指令，程式由該點繼續執行。

堆：一般是在堆的頭部用一個位元組存放堆的大小。堆中的具體內容由程式設計師安排。

參考資料：
http://www.cnblogs.com/lln7777/archive/2012/03/14/2396164.html