Không nên mã này gặp sự cố

Question

int *p; 
while(true) 
{ 
p = new int; 
} 

Do hết dung lượng bộ nhớ, mã này không bị lỗi. Tôi đã thử in ra giá trị của p, đó là địa chỉ của bộ nhớ nằm cho p, và nó có vẻ tăng nhưng chưa có sự cố.

Tại sao lại như vậy?

Answer 1

Giải pháp này cũng giống như cố gắng để sụp đổ xe hơi tại một cột điện thoại xuống các đường phố trong khi lái xe 1MPH. Nó sẽ xảy ra cuối cùng nhưng nếu bạn muốn kết quả nhanh chóng, bạn cần tăng tốc độ một chút.

int *p; 
while (true) { 
    p = new int[1024*1024*1024]; 
} 

Câu trả lời của tôi mặc dù được dựa trên phân bổ bộ nhớ STL tiêu chuẩn. Có các trình phân bổ có sẵn khác mà chỉ cần trả lại NULL về phân bổ không thành công. Loại cấp phát sẽ không bao giờ gặp sự cố trong mã này vì việc phân bổ không thành công không được coi là gây tử vong. Bạn sẽ phải kiểm tra sự trở lại của phân bổ cho NULL để phát hiện lỗi.

Một lưu ý khác, nếu bạn đang chạy trên hệ thống 64 bit, điều này có thể mất thời gian lâu hơn đáng kể do kích thước không gian địa chỉ tăng lên. Thay vì cuộc thăm dò qua điện thoại đang ở trên đường, nó trên khắp đất nước.

Answer 2

Bạn không đợi đủ lâu.

[Nếu bạn muốn xem nó đang tiến triển như thế nào, hãy thêm một số đầu ra trên mỗi vòng 1000000 hoặc một thứ gì đó tương tự. Nó sẽ cuối cùng không thành công.]

Answer 3

Phân bổ cấp độ nhỏ của bộ nhớ nhỏ chậm hơn một phân bổ lớn. Ví dụ, nó sẽ mất nhiều thời gian hơn để phân bổ 4 byte 1 triệu lần, hơn 1 triệu byte 4 lần.

Cố gắng phân bổ khối lớn hơn bộ nhớ cùng một lúc:

int *p; 
while(true) 
{ 
p = new int[1024*1024]; 
} 

Answer 4

Hình như bạn sẽ không đóng câu hỏi này cho đến khi bạn nhìn thấy một vụ tai nạn :)

Trên Unix như hệ điều hành bạn có thể hạn chế dung lượng bộ nhớ ảo có sẵn cho một quá trình sử dụng lệnh ulimit. Bằng cách đặt VM thành 1MB, tôi có thể xem kết quả mong muốn sau khoảng 5 giây:

$ ulimit -v $((1024*1024)) # set max VM available to process to 1 MB 

$ ulimit -v    # check it. 
1048576 

$ time ./a.out    # time your executable. 
terminate called after throwing an instance of 'St9bad_alloc' 
    what(): std::bad_alloc 
Aborted 

real 0m5.502s 
user 0m4.240s 
sys 0m1.108s 

Answer 5

Tôi nghĩ rằng trình biên dịch đang thực hiện tối ưu hóa và không phân bổ bộ nhớ. Tôi chạy các ví dụ trên (bằng cách sử dụng valgrind) một số lần và thấy rằng mặc dù có nơi phân bổ, tất cả các nơi của bộ nhớ 0 byte.

Hãy thử điều này và chương trình của bạn sẽ bị giết (ít nhất là trên unix):

#include <cstdio> 

int main() { 

int *p; 

while (true) { 
     p = new int[1024*1024]; 
     p[0] = 0; 
     printf("%p\n",p); 
     for(unsigned j = 1; j < 1024*1024; j++) { 
       p[j] = p[j-1] + 1; 
     } 
} 

return 0; 
} 

Bạn thấy sự khác biệt duy nhất là tôi sử dụng bộ nhớ được phân bổ.

Vì vậy, nó không thực sự sụp đổ vì tôi đoán hệ điều hành đang ngăn quá trình từ đâm bằng cách chỉ cần giết nó (Không chắc chắn 100% về điều này)

Answer 6

Một khả năng khác: hầu hết các hệ điều hành sẽ thực hiện phân bổ lạc quan. Khi bạn malloc, nói, 500 MB, bộ nhớ đó có thể không thực sự được dành riêng cho đến khi chương trình của bạn thực sự cố gắng đọc hoặc ghi vào nó.

Linux đặc biệt nổi tiếng với bộ nhớ quá hứa hẹn và sau đó dựa vào kẻ giết người OOM (out-of-memory) để whack quá trình cố gắng thu thập trên lời hứa của hạt nhân.