Khi sự kiện tạo ra hàng loạt đối tượng tạm, GC phải chạy thường xuyên hơn nhiều so với bình thường.
Vì sao Vật phẩm rơi ra, log chiến đấu và phần thưởng sự kiện làm số đối tượng tạm tăng vọt → Dẫn đến GC chạy dày gấp mấy lần, các đối tượng chưa kịp bị bỏ đi bị chuyển sang vùng Old, khiến Full GC cũng đến sớm hơn → Trên màn hình Chỉ khựng theo chu kỳ trong lúc có sự kiện
Phụ trách chính Phát triển server (Đội phát triển game)
Việc cần làm (Đội phát triển game)
Object pool, dùng lại bộ đệm, profiling việc cấp phát bộ nhớ.
Trên đồ thị
Tăng theo số người và tải · Số lần GC, tốc độ cấp phát
Chỗ cần xem
Đếm số lần GC mỗi phút qua log GC (Java -Xlog:gc, Go GODEBUG=gctrace=1); với .NET, xem lượng cấp phát và số lần GC trong dotnet-counters (.NET 9 trở đi: dotnet.gc.heap.total_allocated, dotnet.gc.collections; 8 trở xuống: Allocation Rate, Gen 0 GC Count). Đặt chồng với số người chơi đồng thời và thời điểm sự kiện
Đúng nếu
khi sự kiện bắt đầu, tốc độ cấp phát và số lần GC tăng dốc hơn mức tăng số người, các lần dừng ngắn dày lên. Sự kiện kết thúc thì trở lại như cũ
Loại trừ nếu
số lần GC giữ nguyên nhưng mỗi lần dừng dài ra → lượng dữ liệu còn sống đã tăng (mem-gc-thrash, mem-leak)
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Nguồn
Garbage Collector ImplementationOracle Vùng Young đầy thì chạy minor GC, một phần đối tượng sống sót được chuyển sang vùng Old; vùng Old đầy thì thu gom toàn bộ heap (lâu hơn minor GC nhiều); -Xlog:gc ghi một dòng cho mỗi lần GC
dotnet-counters diagnostic tool.NET .NET 9 trở đi hiển thị là dotnet.gc.heap.total_allocated và dotnet.gc.collections, .NET 8 trở xuống là Allocation Rate và Gen 0 GC Count