Khi bạn phân bổ bộ nhớ trên heap, giới hạn duy nhất là RAM trống (hoặc bộ nhớ ảo). Nó làm cho Gb của bộ nhớ.
Vậy tại sao kích thước ngăn xếp lại bị giới hạn (khoảng 1 Mb)? Lý do kỹ thuật nào ngăn cản bạn tạo các đối tượng thực sự lớn trên ngăn xếp?
Cập nhật : Ý định của tôi có thể không rõ ràng, tôi không muốn phân bổ các đối tượng lớn trên ngăn xếp và tôi không cần một ngăn xếp lớn hơn. Câu hỏi này chỉ là sự tò mò thuần túy.
Câu trả lời:
Trực giác của tôi là như sau. Ngăn xếp không dễ quản lý như đống. Ngăn xếp cần được lưu trữ trong các vị trí bộ nhớ liên tục. Điều này có nghĩa là bạn không thể phân bổ ngẫu nhiên ngăn xếp khi cần thiết, nhưng ít nhất bạn cần dành các địa chỉ ảo cho mục đích đó. Kích thước của không gian địa chỉ ảo dành riêng càng lớn, bạn có thể tạo càng ít luồng.
Ví dụ, một ứng dụng 32-bit thường có không gian địa chỉ ảo là 2GB. Điều này có nghĩa là nếu kích thước ngăn xếp là 2MB (như mặc định trong pthreads), thì bạn có thể tạo tối đa 1024 luồng. Điều này có thể nhỏ đối với các ứng dụng như máy chủ web. Tăng kích thước ngăn xếp lên, chẳng hạn, 100MB (tức là bạn dự trữ 100MB, nhưng không nhất thiết phải phân bổ 100MB cho ngăn xếp ngay lập tức), sẽ giới hạn số luồng xuống khoảng 20, điều này có thể hạn chế ngay cả đối với các ứng dụng GUI đơn giản.
Một câu hỏi thú vị là, tại sao chúng ta vẫn có giới hạn này trên nền tảng 64-bit. Tôi không biết câu trả lời, nhưng tôi cho rằng mọi người đã quen với một số "phương pháp hay nhất về ngăn xếp": hãy cẩn thận phân bổ các đối tượng khổng lồ trên heap và nếu cần, hãy tăng kích thước ngăn xếp theo cách thủ công. Do đó, không ai thấy hữu ích khi thêm hỗ trợ ngăn xếp "khổng lồ" trên nền tảng 64-bit.
Một khía cạnh mà chưa ai đề cập đến:
Kích thước ngăn xếp hạn chế là một cơ chế phát hiện và ngăn chặn lỗi.
Nói chung, công việc chính của ngăn xếp trong C và C ++ là theo dõi ngăn xếp cuộc gọi và các biến cục bộ, và nếu ngăn xếp phát triển vượt quá giới hạn, thì hầu như luôn luôn là lỗi trong thiết kế và / hoặc hành vi của ứng dụng. .
Nếu ngăn xếp được phép tăng lớn tùy ý, những lỗi này (như đệ quy vô hạn) sẽ bị bắt rất muộn, chỉ sau khi tài nguyên hệ điều hành cạn kiệt. Điều này được ngăn chặn bằng cách đặt giới hạn tùy ý cho kích thước ngăn xếp. Kích thước thực tế không quan trọng lắm, ngoài việc nó đủ nhỏ để ngăn chặn sự xuống cấp của hệ thống.
std::unique_ptrđể viết hàm hủy (và không dựa vào con trỏ thông minh)).
Nó chỉ là một kích thước mặc định. Nếu bạn cần nhiều hơn, bạn có thể nhận được nhiều hơn - thường xuyên nhất bằng cách yêu cầu trình liên kết phân bổ thêm không gian ngăn xếp.
Nhược điểm của việc có nhiều ngăn xếp là nếu bạn tạo nhiều luồng, mỗi luồng sẽ cần một ngăn xếp. Nếu tất cả các ngăn xếp đang phân bổ nhiều MB, nhưng không sử dụng nó, không gian sẽ bị lãng phí.
Bạn phải tìm sự cân bằng thích hợp cho chương trình của mình.
Một số người, như @BJovke, tin rằng bộ nhớ ảo về cơ bản là miễn phí. Đúng là bạn không cần phải có bộ nhớ vật lý hỗ trợ tất cả bộ nhớ ảo. Ít nhất bạn phải có khả năng cung cấp địa chỉ cho bộ nhớ ảo.
Tuy nhiên, trên một PC 32 bit điển hình, kích thước của bộ nhớ ảo cũng giống như kích thước của bộ nhớ vật lý - bởi vì chúng ta chỉ có 32 bit cho bất kỳ địa chỉ nào, dù là ảo hay không.
Bởi vì tất cả các luồng trong một tiến trình chia sẻ cùng một không gian địa chỉ, chúng phải phân chia nó giữa chúng. Và sau khi hệ điều hành thực hiện xong, chỉ còn lại 2-3 GB cho một ứng dụng. Và kích thước đó là giới hạn cho cả bộ nhớ vật lý và bộ nhớ ảo, bởi vì không còn địa chỉ nào nữa.
Thứ nhất, ngăn xếp là liên tục, vì vậy nếu bạn phân bổ 12MB, bạn phải xóa 12MB khi muốn xuống dưới bất kỳ thứ gì bạn đã tạo. Ngoài ra, việc di chuyển các đối tượng xung quanh trở nên khó khăn hơn nhiều. Đây là một ví dụ thực tế có thể giúp mọi thứ dễ hiểu hơn:
Giả sử bạn đang xếp các hộp xung quanh phòng. Cái nào dễ quản lý hơn:
Hai ví dụ đó là những khái quát tổng quát và có một số điểm sai một cách trắng trợn trong phép loại suy nhưng nó đủ gần để hy vọng nó sẽ giúp bạn thấy được lợi thế trong cả hai trường hợp.
Hãy nghĩ về ngăn xếp theo thứ tự từ gần đến xa. Các thanh ghi ở gần CPU (nhanh), ngăn xếp xa hơn một chút (nhưng vẫn tương đối gần) và đống ở xa (truy cập chậm).
Tất nhiên, ngăn xếp tồn tại trên heap, nhưng vẫn còn, vì nó được sử dụng liên tục, nó có thể không bao giờ rời khỏi (các) bộ nhớ cache của CPU, làm cho nó nhanh hơn so với chỉ truy cập heap thông thường. Đây là một lý do để giữ cho ngăn xếp có kích thước hợp lý; để giữ nó được lưu trong bộ nhớ cache nhiều nhất có thể. Phân bổ các đối tượng ngăn xếp lớn (có thể tự động thay đổi kích thước ngăn xếp khi bạn bị tràn) đi ngược lại nguyên tắc này.
Vì vậy, đó là một mô hình tốt cho hiệu suất, không chỉ là một thứ còn sót lại từ thời xưa.
Nhiều thứ bạn nghĩ rằng bạn cần một ngăn xếp lớn, có thể được thực hiện theo cách khác.
"Thuật toán" của Sedgewick có một vài ví dụ điển hình về việc "loại bỏ" đệ quy khỏi các thuật toán đệ quy như QuickSort, bằng cách thay thế đệ quy bằng phép lặp. Trong thực tế, thuật toán vẫn là đệ quy, và vẫn có ngăn xếp, nhưng bạn phân bổ ngăn xếp sắp xếp trên heap, thay vì sử dụng ngăn xếp thời gian chạy.
(Tôi thích ấn bản thứ hai, với các thuật toán được đưa ra trong Pascal. Nó có thể được sử dụng với giá tám đô la.)
Một cách khác để xem xét nó, là nếu bạn nghĩ rằng bạn cần một ngăn xếp lớn, thì mã của bạn không hiệu quả. Có một cách tốt hơn là sử dụng ít ngăn xếp hơn.
Tôi không nghĩ rằng có bất kỳ lý do kỹ thuật nào, nhưng nó sẽ là một ứng dụng kỳ lạ chỉ tạo ra một siêu vật thể khổng lồ trên ngăn xếp. Các đối tượng ngăn xếp thiếu tính linh hoạt trở nên khó khăn hơn khi tăng kích thước - bạn không thể quay lại mà không hủy chúng và bạn không thể xếp chúng vào các luồng khác.
int main() { char buffer[1048576]; } Đó là một vấn đề rất phổ biến của người mới. Chắc chắn có một cách giải quyết dễ dàng, nhưng tại sao chúng ta phải giải quyết kích thước ngăn xếp?