Có bao nhiêu cuộc gọi hàm quá nhiều lồng nhau?

Trích dẫn từ MSDN về StackOverflowException :

Ngoại lệ được ném khi ngăn xếp thực thi tràn vì nó chứa quá nhiều lệnh gọi phương thức lồng nhau.

Too manyở đây khá mơ hồ. Làm thế nào để tôi biết khi quá nhiều thực sự là quá nhiều? Hàng ngàn chức năng gọi? Hàng triệu? Tôi giả định rằng nó phải liên quan theo một cách nào đó đến dung lượng bộ nhớ trong máy tính nhưng liệu có thể đưa ra một thứ tự độ lớn gần như chính xác?

Tôi lo ngại về điều này bởi vì tôi đang phát triển một dự án liên quan đến việc sử dụng nhiều cấu trúc đệ quy và các lệnh gọi hàm đệ quy. Tôi không muốn ứng dụng bị lỗi khi tôi bắt đầu sử dụng nó không chỉ là các thử nghiệm nhỏ.

Tôi lo ngại về điều này bởi vì tôi đang phát triển một dự án liên quan đến việc sử dụng nhiều cấu trúc đệ quy và các lệnh gọi hàm đệ quy. Tôi không muốn ứng dụng bị lỗi khi tôi bắt đầu sử dụng nó không chỉ là các thử nghiệm nhỏ.

Trừ khi môi trường ngôn ngữ của bạn hỗ trợ tối ưu hóa cuộc gọi đuôi (và đệ quy của bạn là cuộc gọi đuôi), một nguyên tắc cơ bản là: độ sâu đệ quy phải được đảm bảo là O (log n), tức là sử dụng thuật toán hoặc cấu trúc dữ liệu dựa trên phân chia và chinh phục (như cây, hầu hết các trường hợp sắp xếp, v.v.) là OK, nhưng bất cứ điều gì tuyến tính (như triển khai đệ quy của xử lý danh sách liên kết) thì không.

Theo mặc định, CLR phân bổ 1 MB cho ngăn xếp cho mỗi luồng (xem bài viết này ). Vì vậy, tuy nhiên nhiều cuộc gọi cần phải vượt quá số tiền này. Điều đó sẽ thay đổi tùy thuộc vào lượng không gian trên ngăn xếp mà mỗi cuộc gọi đang sử dụng cho những thứ như tham số và biến cục bộ.

Bạn thậm chí có thể thực hiện StackOverflowExceptioncuộc gọi bằng một cuộc gọi duy nhất nếu bạn muốn có một chút không chính thống:

private static unsafe void BlowUpTheStack()
{
    var x = stackalloc byte[1000000000];
    Console.WriteLine("Oh no, I've blown up the stack!");
}

Vì Cole Campbell lưu ý kích thước bộ nhớ và Michael Borgwardt lưu ý tối ưu hóa cuộc gọi đuôi, tôi sẽ không bao gồm những điều đó.

Một điều khác cần lưu ý là CPS có thể được sử dụng để tối ưu hóa một số chức năng đan xen trong đó tối ưu hóa cuộc gọi đuôi là cho các chức năng đơn lẻ.

Bạn có thể tăng kích thước của ngăn xếp như chúng tôi đã làm ở đây và lưu ý rằng mã 64 bit ăn ngăn xếp nhanh hơn mã 32 bit.

Đáng chú ý là chúng tôi đã chạy một trong các ví dụ trong tương tác F # trong hơn 40 giờ mà không thổi tung ngăn xếp. Vâng, đó là một cuộc gọi chức năng chạy liên tục để hoàn thành thành công.

Ngoài ra, nếu bạn cần thực hiện bảo hiểm mã để tìm ra nơi xảy ra sự cố và không có phạm vi bảo hiểm mã với VS bạn có thể sử dụng, TestDriven.NET