Khi Thu Hồi Bộ Nhớ Dừng Xử Lý Công Việc: Hiệu Năng Hệ Thống và Nguyên Nhân Garbage Collection Đình Trệ Đúng Lúc Đáng Lo Ngại Nhất

27/9/2026 ·

Hầu hết các nhóm đều kỳ vọng hệ thống IT sẽ chậm lại dưới tải nặng, nhưng một số lần chậm frustrasi nhất lại xảy ra khi lưu lượng chưa đạt đỉnh. Một request thường chỉ mất 40 mili giây bỗng mất 800 mili giây rồi trở lại bình thường. Nhật ký không hiển thị deadlock cơ sở dữ liệu, CPU chưa bão hòa và mạng vẫn ổn định. Trong các runtime quản lý như Java, .NET, Go hoặc Node.js, một giải thích phổ biến là quá trình thu hồi bộ nhớ. Thu gom rác tự động giữ ứng dụng an toàn trước lỗi bộ nhớ thủ công, nhưng nếu không được hiểu và quan sát đúng, nó có thể dừng xử lý công việc đúng lúc đáng lo ngại nhất.

Garbage Collection Hoạt Động Thế Nào và Tại Sao Nó Dừng Công Việc

Garbage collection, hay GC, là cách runtime thu hồi bộ nhớ mà ứng dụng không còn cần đến. Khi mã của bạn tạo đối tượng, chuỗi, mảng và các cấu trúc khác, chúng chiếm dung lượng trên heap. Khi những đối tượng đó không còn khả năng truy cập, trình thu gom xác định chúng và giải phóng bộ nhớ để phân bổ sau. Sự tự động hóa này ngăn rò rỉ và con trỏ treo, nhưng nó đòi hỏi công việc. Để xác định cái gì còn sống và cái gì có thể loại bỏ, runtime thường cần tạm dừng hoặc làm chậm các luồng ứng dụng.

Những lần dừng này đôi khi được gọi là sự kiện stop-the-world. Không phải trình thu gom nào cũng dừng mọi thứ trong thời gian dài. Các trình thu gom hiện đại được tối ưu hóa cao và sử dụng kỹ thuật đồng thời, tăng dần và theo thế hệ để thực hiện hầu hết công việc trong nền. Tuy nhiên, một số giai đoạn vẫn cần cái nhìn nhất quán về đồ thị đối tượng, nghĩa là phải dừng các luồng mutator. Bản thân lần dừng có thể chỉ kéo dài vài mili giây, nhưng tác động lên độ trễ có thể lớn hơn nhiều nếu nó xảy ra trong lúc một request面向 người dùng đang được xử lý.

Sự Cân Nhắc Giữa Thông Suất và Độ Trễ

Các garbage collector khác nhau ưu tiên mục tiêu khác nhau. Trình thu gom hướng thông suất nhằm tối đa hóa tổng công việc hoàn thành và có thể chấp nhận lần dừng dài hơn nhưng ít xảy ra hơn. Trình thu gom độ trễ thấp nhằm giữ lần dừng ngắn và có thể dự đoán được, ngay cả khi nó sử dụng nhiều CPU hơn tổng thể. Không có lựa chọn nào ưu việt tuyệt đối. Sự cân bằng đúng phụ thuộc vào việc ứng dụng của bạn phục vụ request tương tác, xử lý công việc nền hay làm cả hai. Hiểu sự cân nhắc này giúp giải thích tại sao hai dịch vụ có mã tương tự có thể hiển thị hồ sơ độ trễ rất khác nhau sau khi nâng cấp runtime hoặc thay đổi cấu hình.

Dấu Hiệu Cho Thấy Thời Gian Dừng Thu Gom Rác Gây Đỉnh Thời Gian Phản Hồi

GC pause không phải lúc nào cũng thông báo rõ ràng, đó là lý do chúng thường bị nhầm lẫn với rung động mạng hoặc độ chậm phía downstream. Việc học các dấu hiệu cho thấy thời gian dừng thu gom rác gây đỉnh thời gian phản hồi giúp bạn tách các độ trễ liên quan đến bộ nhớ khỏi các vấn đề hiệu năng khác. Mẫu thường rất đặc trưng khi bạn biết cần tìm gì.

Một trong những dấu hiệu rõ ràng nhất là đỉnh định kỳ ảnh hưởng đến nhiều request cùng lúc. Thay vì chỉ một endpoint chậm, bạn thấy một đợt ngắn tăng độ trễ trên nhiều endpoint hoặc dịch vụ chạy trên cùng một runtime instance. Các đỉnh này tương ứng với sự kiện GC trong nhật ký runtime, không phải với đỉnh lưu lượng đầu vào. Giữa các sự kiện đó, thời gian phản hồi trở lại baseline ổn định.

Độ trễ ngoại lệ ngắn định kỳ: p50 của bạn vẫn bằng phẳng trong khi p95 và p99 hiển thị các đỉnh sắc, lặp lại mỗi vài giây hoặc vài phút. Khoảng cách này thường phù hợp với tốc độ phân bổ và mức sử dụng heap.
Tương quan với áp lực phân bổ: Các đỉnh xuất hiện sau các lần triển khai tăng tạo đối tượng, chẳng hạn thêm logging chi tiết, tải JSON lớn hơn hoặc nối chuỗi không hiệu quả trong hot path.
Các lần dừng đồng bộ trên các luồng: Thread dump hoặc chỉ số ứng dụng cho thấy nhiều luồng request bị chặn hoặc dừng tại cùng một timestamp, không có lock contention nào được báo cáo.
Nhật ký và chỉ số GC khớp với trace chậm: Khi bạn chồng thời lượng GC pause lên dữ liệu tracing, các span chậm khớp chính xác với các lần dừng được báo cáo. Mức sử dụng heap giảm ngay sau mỗi đỉnh, cho thấy đã xảy ra lần thu gom.
Độ trễ cải thiện sau khi điều chỉnh heap hoặc GC: Tăng kích thước heap, điều chỉnh kích thước thế hệ hoặc chuyển sang trình thu gom độ trễ thấp giảm chiều cao hoặc tần suất đỉnh mà không cần thay đổi mã ứng dụng.

Nếu bạn quan sát hai hoặc ba dấu hiệu này cùng lúc, GC là ứng cử viên mạnh. Nếu các đỉnh ngẫu nhiên, chỉ giới hạn ở một endpoint hoặc không tương ứng với hoạt động thu gom, khả năng cao có bottleneck khác.

Tại Sao Các Lần Dừng Xảy Ra Đúng Lúc Đáng Lo Ngại Nhất

Có thể cảm giác như GC cố tình đợi lúc bận nhất, nhưng nguyên nhân cơ học hơn. Các lần dừng trở nên rõ ràng khi ứng dụng đang làm công việc hữu ích nhạy cảm với độ trễ. Trong thời gian nhàn rỗi, lần dừng 50 mili giây không được chú ý vì không có request nào đang chờ. Trong giờ cao điểm kinh doanh, cùng một lần dừng đó làm chậm hàng chục request đồng thời và xuất hiện như một đỉnh trên bảng điều khiển của bạn.

Tốc độ phân bổ là y��u tố khác. Khi dịch vụ của bạn xử lý nhiều request hơn, nó tạo ra nhiều đối tượng tạm thời hơn. Phân bổ nhanh hơn làm đầy heap nhanh hơn, kích hoạt các lần thu gom thường xuyên hơn. Các phân bổ đối tượng lớn, chẳng hạn buffer lớn, kết quả truy vấn được lưu trong bộ nhớ đệm hoặc phản hồi được tuần tự hóa, có thể đẩy nhanh chu kỳ này. Sự phân mảnh và lỗi thăng cấp trong các thế hệ cũ cũng có thể buộc các lần thu gom toàn bộ dài hơn đúng lúc áp lực bộ nhớ cao nhất. Kết quả là vòng lặp phản hồi: tải lớn tạo ra nhiều rác hơn, tạo ra nhiều công việc thu gom hơn, thêm độ trễ vào tải bạn đang cố gắng phục vụ.

Cách Nhìn Thấy và Đo Lường GC Pause

Bạn không thể quản lý những gì không thể nhìn thấy. May mắn thay, hầu hết các runtime hiện đại đều hiển thị hành vi GC chi tiết mà không cần thay đổi mã. Chìa khóa là thu thập cả dữ liệu cấp runtime và cấp ứng dụng rồi xem chúng cùng nhau.

Bật nhật ký GC: Ở Java, bật nhật ký GC với các cờ báo cáo thời gian dừng, nguyên nhân và heap trước và sau. Ở .NET, sử dụng GC event counters. Ở Go, sử dụng GC trace và runtime metrics. Ở Node.js, sử dụng –trace-gc và performance hooks. Giữ các nhật ký này trên nền tảng quan sát trung tâm của bạn.
Theo dõi chỉ số heap và phân bổ: Giám sát kích thước heap, heap sử dụng sau lần thu gom, tốc độ phân bổ và tốc độ thăng c��p. Tốc độ phân bổ tăng với lưu lượng ổn định thường báo trước các lần dừng dài hơn.
Tương quan với độ trễ request: chồng đường thời gian GC pause lên trên các percentile thời gian phản hồi và distributed trace. Tìm sự thẳng hàng ở p95 và p99 thay vì giá trị trung bình, vì trung bình che giấu ngoại lệ.
Sử dụng chỉ số safepoint và runtime pause: Một số nền tảng báo cáo safepoint pause hoặc thời gian tạm dừng runtime riêng biệt với GC. Những chỉ số này giúp phân biệt GC pause với các lần dừng runtime khác như thu hồi biased lock hoặc deoptimization mã.
Profile việc tạo đối tượng: Sử dụng allocation profiler hoặc heap dump để tìm các điểm nóng tạo ra quá nhiều đối tượng tạm thời. Thường một đường dẫn mã nhỏ chịu trách nhiệm cho một phần lớn rác.

Khi đo lường, tập trung vào phân phối thời lượng dừng, không chỉ tổng thời gian GC. Một trình thu gom dành 2% tổng thời gian trong GC vẫn có thể tạo ra các lần dừng 200 mili giây vi phạm mục tiêu mức dịch vụ, trong khi trình thu gam dành 5% với các lần dừng 5 mili giây có thể mượt mà hơn cho người dùng.

Phải Làm Gì Tiếp Theo Mà Không Đoán Mò

Khi bạn đã xác nhận GC góp phần vào độ trễ, tránh điều chỉnh mù quáng. Các thay đổi nhỏ, dựa trên bằng chứng hiệu quả hơn so với việc tăng heap lớn chỉ trì hoãn vấn đề.

Giảm áp lực phân bổ trước: Tái sử dụng buffer khi an toàn, tránh boxing không cần thiết, giới hạn tạo chuỗi trung gian và phát trực tuyến tải lớn thay vì hiện thực hóa chúng hoàn toàn trong bộ nhớ. Điều này giảm tần suất trình thu gom phải chạy.
Phù hợp trình thu gom với khối lượng công việc: Đối với dịch vụ nhạy cảm với độ trễ, xem xét các trình thu gom được thiết kế cho thời gian dừng thấp, chẳng hạn ZGC hoặc Shenandoah trên các phiên bản Java gần đây, hoặc các chế độ server GC đồng thời trong .NET. Kiểm tra thay đổi dưới tải thực tế trước khi áp dụng.
Điều chỉnh kích thước heap phù hợp: Heap quá nhỏ gây ra các lần thu gom thường xuyên, trong khi heap quá lớn có thể làm mỗi lần thu gom dài hơn. Kiểm tra tải với các kích thước heap khác nhau và quan sát phân phối và tần suất dừng.
Cô lập khối lượng công việc: Tách xử lý request nhạy cảm với độ trễ khỏi các công việc nền tốn bộ nhớ. Chạy chúng trong các tiến trình hoặc container khác nhau ngăn công việc batch kích hoạt các lần dừng trên đường dẫn面向 người dùng.
Đặt cảnh báo trên mẫu dừng: Cảnh báo trên thời lượng dừng p99 và tần suất dừng, không chỉ mức sử dụng heap. Heap ổn định vẫn có thể che giấu hành vi dừng có vấn đề.

Thu hồi bộ nhớ là cần thiết, nhưng nó không nhất thiết phải bí ẩn. Bằng cách thu thập đúng tín hiệu và học cách nhận ra khi công việc thu gom ngắt quá trình xử lý request, các nhóm có thể đưa ra các quyết định bình tĩnh, có mục tiêu giữ thời gian phản hồi có thể dự đoán được ngay cả khi nhu cầu cao.