要精通一門語言，熟悉其內容分配和使用機制很重要。對于編譯型語言比如C，C++，內存的使用完全由程序員自己代碼分配和管理，所以對C，C++程序員內存機制非常熟悉。但是對于動態語言，比如Python，內存在語言層自動管理，所以程序員無需關注太多細節，但是如果要想自己寫的代碼高效可靠，則也必須了解語言的內存機制。本文蟲蟲給大家介紹Python語言的內存機制，以及如何對其內存進行度量。

概述

考慮以下代碼：

import numpy as np 
cc= np.ones((1024, 1024, 1024, 3), dtype=np.uint8) 

該代碼將會創建一個3GB字節的數組，并且都用1來填充。同學們，可能會這樣預想運行該代碼后，進程將會自動分配3GB的內存用來使用，事實是不是如此呢?

測量內存的一種方法是使用“常駐內存”，在Python中可以使用psutil庫工具獲取方便的這些信息，檢查當前進程的常駐內存：

import psutil 
psutil.Process().memory_info().rss /(1024 * 1024) 
3093 

在該示例中，進程使用了3093MB或3.09GB，與數組大小的無區別，和預想的一樣。

但是常駐內存實際上沒那么簡單。假設在機器上運行一些耗內存的任務。然后切換回解釋器，再次運行完全相同的命令：

psutil.Process().memory_info().rss / (1024 * 1024) 
2903.12109375 

這是怎么回事? 內存少了200MB。

為了解釋這個現象，需要了解操作系統如何內存管理機制。

簡化模型

當前正運行的程序都會分配一些內存，即從操作系統取回虛擬內存中的地址。 虛擬內存是一個特定于進程的地址空間，本質上是來自0至264-1，進程可以讀取或寫入字節。

在C語言中，程序員可以使用malloc()或者mmap()函數進行手動內存分配;而在Python中，我們只需創建對象，Python 解釋器將在底層自動調用malloc()或者mmap()。然后該進程可以讀取或寫入該特定地址和連續字節。

Linux下可以用ltrace工具跟蹤調用malloc()，運行下面Python代碼：

import numpy as np 
cc = np.ones((170_000,), dtype=np.uint8) 

然后可以運行ltrace：

ltrace -e malloc python ones.py 
... 
_multiarray_umath.cpython-39-x86_64-linux-gnu.so->malloc(170000) = 0x5638862a45e0 
... 

整個過程Python 創建一個NumPy數組。

在Python引擎NumPy調用malloc()。

這樣做的結果malloc()是內存中的地址：0x5638862a45e0。

然后，用于實現NumPy的C代碼可以讀取和寫入該地址和下一個連續的169,999 個地址，每個地址代表虛擬內存中的一個字節。

這 170,000個字節存儲在哪里?

它們可以存儲在RAM中;這是默認設置。

它們可以存儲在計算機的硬盤驅動器或磁盤上，即swap分區交換中。

一些字節可能存儲在 RAM 中，一些字節可能存儲在交換分區中。

常駐內存

RAM很快，而硬盤IO很慢，但RAM很貴。通常電腦硬盤驅動器空間比RAM多得多。例如，目前主流的計算機都會有2T左右的硬盤存儲空間，但只會16GB的RAM。

理想情況下，程序的所有內存都將存儲在內存RAM中，但計算機上運行的各種進程可能分配的內存比RAM中可用的內存多。如果發生這種情況，操作系統會將一些數據從RAM移動或“交換”到硬盤驅動器。必要時，從交換分區中獲取數據，并將未積極使用的數據置換進去。

現在我們準備定義我們的第一個內存使用量度：常駐內存。常駐內存是進程分配的內存中有多少常駐或存儲在RAM中。

在第一個示例中，首先將所有3GB的已分配數組存儲在RAM中。

然后，當運行一些任務時，加載這些任務需要分配很多RAM，因此操作系統會將一些數據從RAM交換到磁盤交換分區。結果，Python進程的常駐內存下降了：所有數據仍然可以訪問，但其中一些已移至磁盤交換分區。

分配內存

測量分配內存會很有用，無論操作系統是將數據放在RAM中還是將其交換到磁盤，總是3GB內存，程序實際需要多少內存。

在 Python 中(如果使用的是Linux 或macOS)，可以使用Fil memory profiler測量分配的內存，它專門測量峰值分配的內存。對于之前的示例：

常駐內存和分配內存之間的權衡

常駐內存存在一些問題：

• 內存的使用和測量會受到其他進程的影響，由于其他進程可能會爭搶常駐內存導致使用的實際使用的RAM會變化。
• 常駐內存的上限是可用的物理RAM，所以一旦達到上限，就永遠不會真正了解程序要求多少內存。比如主機物理內存16GB，對需要17GB內存的程序和需要30GB 內存的程序，它們駐留內存的量都將一致，都將是16GB。
• 另一方面，分配的內存不受其他進程的影響，并告訴程序實際請求的內容。

當然，常駐內存確實比分配內存的優勢：

• 交換的內存很可能永遠不會被使用：想象一下創建一個數組，忘記刪除引用，然后在程序的其余部分不再實際使用它。
• 更廣泛地說，由于駐留內存從操作系統的角度衡量實際使用的內存，因此它可以捕獲對分配的內存跟蹤不可見的邊緣情況。

讓我們看一個這樣的邊緣情況的例子。

總結

到目前為止示例中，我們一直在分配充滿1的數組。如果測量已分配的內存，則數組填充的內容沒有區別：可以切換到創建充滿零的數組，并且仍然得到完全相同的結果。

但是在Linux 上，再看一個例子：

import numpy as np 
import psutil 
arr = np.zeros((1024, 1024, 1024, 3), dtype=np.uint8) 
psutil.Process().memory_info().rss/(1024 * 1024) 
28.5546875 

這次，還是分配了一個3GB的數組，但是給數組的元素都是零。然后測量常駐內存——數組并沒有被計算到，常駐內存只有29M。數組占用的內存呢?

事實證明，Linux 不會費心將所有這些零存儲在RAM中。而只是在實際訪問數據時向RAM添加零塊，并不會實際分配內存。

最后，需要提及的是，我們在說的內存使用模型也是理想狀態的。還沒有包括文件緩存、分配器中的內存碎片或其他可用指標等。

話雖如此，對于許多應用程序來說，分配的內存可能足以作為幫助優化程序內存使用的必要措施。