Mẫu AJAX này có bị rò rỉ bộ nhớ không?

Question

Hãy xem xét ví dụ này của phương pháp khá tiêu chuẩn trong góc Js, cập nhật quan điểm:

$scope.fetchResults = function() { 
    // Some local variable that will cause creation of closure 
    var hugeData = serviceX.getMilionRecords(); 

    // Any call to any resource with success and error handlers. 
    $http({ 
     method: "GET", 
     url: "/rest-api/bulk-operation-x", 
     params: { someParam: hugeData.length } 

    }).success(function() { 
     var length = hugeData.length; 
     $scope.reportToUser("Success, that was " + length + " records being processed!"; 

    }).error(function() { 
     var length = hugeData.length; 
     $scope.reportToUser("Something went wrong while processing " + length + " records... :-("; 
    }); 
}; 

Đây là khóa học ví dụ giả, nhưng nó độc đáo cho thấy mô hình, có thể được mô tả như tái sử dụng các biến địa phương từ bên trong Gọi lại AJAX.

Tất nhiên trong cả hai trình xử lý (success và error) chúng tôi đang tạo một đóng trên hugeData được tham chiếu trực tiếp từ trình xử lý gọi lại.

Câu hỏi của tôi là: vì kết quả của cuộc gọi AJAX chỉ có thể thành công hay thất bại, việc tái sử dụng mã này có gây ra rò rỉ bộ nhớ theo thời gian không? Tôi sẽ trả lời "có", nhưng tôi không thể chứng minh một cách đáng tin cậy điều này trong các bài kiểm tra địa phương của tôi.

Tôi muốn một số chuyên gia có kinh nghiệm hơn để giải thích vấn đề này cho tôi. Tôi rất thích phản ứng của bất cứ ai làm việc với Angular trên cơ sở hàng ngày, nhưng bất kỳ phản ứng jquery cũng được chào đón.

Answer 1

Bạn sẽ bị rò rỉ bộ nhớ ngay khi bạn trả lại kết quả cuộc gọi $http() (hoặc bất kỳ đối tượng hoặc chức năng nào có quyền truy cập hugeData) vào phạm vi ngoài của fetchResults.

Với mã của bạn, không có gì lớn được hiển thị trực tiếp bên ngoài fetchResults và kết quả cuộc gọi $http() sẽ hoạt động cho đến khi thành công hoặc không thành công, sau đó gọi lại cuộc gọi tương ứng, cuối cùng nhận được GC'ed.

Xem cho những hiểu biết: http://jibbering.com/faq/notes/closures/#clIdRes

Như @ ŁukaszBachman quan sát, điều này không đảm bảo rằng không có rò rỉ bộ nhớ. Bất kỳ tham chiếu lơ lửng nào đối với đối tượng lớn của bạn hoặc để gọi lại của bạn với đối tượng lớn trong phạm vi, sẽ gây ra sự khốn khổ.

Vì vậy, hãy kiểm tra triển khai $q ($http được dựa trên $q).

Nếu bạn kiểm tra https://github.com/angular/angular.js/blob/master/src/ng/q.js#L191, bạn có thể thấy rằng resolve() phương pháp của các bản sao đầu tiên hoãn lại danh sách các callbacks đăng ký tại một biến địa phương để phương pháp:

var callbacks = pending; 

sau đó làm vô hiệu bên ngoài pending (mà đã được xác định ở cấp độ defer)

pending = undefined; 

sau đó, đánh dấu tiếp theo, thực hiện cuộc gọi lại. Mọi thứ có thể trở nên phức tạp bởi thực tế là đối số của cuộc gọi lại có thể bị trì hoãn (thêm một sự trì hoãn nữa để thực hiện), nhưng nhiều nhất bạn có thể đi vào vòng lặp vô hạn. (Và đó không phải là buồn cười!). Nếu bạn đủ may mắn không nhận được vào vòng lặp, sau đó tại một số điểm mảng gọi lại là kiệt sức, và sau đó không có tài liệu tham khảo nào cho danh sách gọi lại, do đó, nó có sẵn cho GC.

Nhưng.

Mọi thứ có thể xảy ra nếu bạn buộc họ.

Bạn có thể sử dụng arguments.callee bên trong một cuộc gọi lại.

Bạn cũng có thể ném bia trên bàn phím của mình.

Nếu bạn nhảy ra ngoài cửa sổ, trừ khi bạn sống ở tầng một, có thể bạn sẽ bị thương.

Chúc mừng EcmaScripting!