1樓：
在Linux中，malloc的時候你還沒有得到這塊記憶體。
當你對記憶體實際讀寫的時候才分配。
所以你可以開一百個程序，每個程序分配1G的記憶體，然後不對該區域進行任何讀寫操作，就直接讓程序去睡覺，會發現這個分配了100G記憶體的系統系統並沒有任何異常與崩潰。
這個原理告訴我們乙個道理，就是在Linux中malloc返回有效的值並不意味著你的記憶體真的是可用的。實際上一般而言Linux程式設計都不需要處理malloc返回值為空的情況，因為這它只在極少數情況下出現。
2樓：
對於86：
1.記憶體組織層次：頁式管理—>(numa)—>node的zonelist—>32位DMA/NORMAL/HIGHMEM三個區，64位沒有高階記憶體—>夥伴分配系統—>slab/slub/slob
2.建立程序時記憶體分配：實際上只分配task_struct和thread_info的記憶體，而且很可能是從slab快取中分配的，當程序執行時由於缺頁中斷，才由核心層具體分配物理記憶體並與vm掛接
3.malloc是c runtime中的實現，是上層庫的記憶體分配層，至於核心層的，可以看看__alloc_pages/alloc_pages/kmalloc(小記憶體直接slab，大記憶體還是alloc_pages)/vmalloc(alloc_page分配不連續的物理頁，對映到連續的vm_struct中的pages指標陣列)/vmap/map_vm_area等幾個函式
注：以上針對linux—3.19.3
3樓：剛剛
給程序分配記憶體是分配的記憶體區域，沒有實際分配記憶體，當程式實際操作這塊記憶體時產生缺頁異常，通過缺頁異常來實際分配頁框給程序，詳見ulk頁表和記憶體管理兩章
4樓：
malloc這個函式申請的記憶體是「假的」記憶體呢。
每乙個程式執行的時候會自己維護乙個虛擬記憶體，通常來說，這個虛擬記憶體的大小可能是4G（64位也是4G嗎）。
malloc這一類函式都是在這個記憶體中對記憶體進行分配的。
然後就是核心以輪轉（？）的方式來檢視記憶體是否有變化，然後再建立和物理記憶體之間的對映（不要問我怎麼對映的，我不知道呀）。
然後就是，回答了那麼些，其實發現壓根沒有回答題主的問題。
Linux 的記憶體分配問題。
海楓 其實這個話題分成兩個部分 虛擬記憶體分配與空閒物理記憶體的關係 如果物理記憶體不足了，核心會怎麼辦如果單單從Linux的虛擬記憶體角度理解，虛擬記憶體和物理記憶體是沒有直接關係的。當程序mmap一塊記憶體時，Linux只是給她分配乙個虛擬記憶體空間，只有等她使用該空間時，才分配物理記憶體。理論...
每天有半天空閒時間，應該怎麼管理安排這空閒時間做些有意義的事情呢？
eric chen 將風險交給外包公司日本公司傾向於在內部覆蓋和擁有所有職能。因為他我們相信，貫穿始終並且無所不能的價值是最重要的。此外，日本公司也傾向於擔心有太多的領域無法控制，他們無法下定決心要開放。最近，一些大型零售商通過推出私人品牌產品來內化製造能力，但我認為在大多數情況下，這是與時代潮流相...
Linux 多程序共享記憶體資料？
Xi Yang 這麼複雜的配置體系，起個MongoDB專門管這事怎麼樣？鑑於你已經有一坨XML體系了，那不妨弄個指令碼程序，專門負責讀取XML並且設定MongoDB的庫內容。資料庫我不是很熟悉。如果MongoDB太重，那就找個更輕量的非關聯式資料庫。 大寬寬 簡單搞的話，用mmap做一下呢？就是每個...