Các nhà phát triển java có nên biết về các thuật toán thu gom rác không? [đóng cửa]


11

Gần đây tôi đã được hỏi trong một cuộc phỏng vấn nếu tôi biết về bất kỳ thuật toán thu gom rác nào.

Tôi biết bộ sưu tập rác là gì nhưng tôi chưa bao giờ thực sự nghĩ đến việc tìm hiểu về các thuật toán thu gom rác vì là một nhà phát triển, tôi không bao giờ phải lo lắng về nó và người thu gom rác làm tất cả công việc khó khăn cho tôi.

Các bạn có nghĩ rằng các nhà phát triển Java nên biết về các thuật toán thu gom rác không? Nếu có, bạn có thể cho tôi biết những gì tôi nên xem xét?



1
Vâng, họ nên. Nếu không, họ có nguy cơ viết phần mềm bị hỏng dưới tải nặng.
quant_dev

Câu trả lời:


9

Tôi nghĩ rằng việc biết các thuật toán thu gom rác hoàn toàn không quan trọng nếu bạn phát triển "phần mềm tiêu chuẩn" chứ không phải nền tảng phần mềm. Bạn nên có một sự hiểu biết cơ bản về cách thức hoạt động của công cụ thu gom rác và đó là về nó. Trừ khi bạn gặp phải sự chậm trễ nghiêm trọng trong phần mềm do bộ sưu tập rác gây ra hoặc bạn cần tối ưu hóa việc sử dụng bộ nhớ.

Nếu bạn quan tâm đến các thuật toán đó, vui lòng xem bài đăng này của tôi: các thuật toán đằng sau GC tạm dừng thấp là gì?


7

Bộ sưu tập rác là một vấn đề khoa học máy tính thú vị, không tầm thường.

Biết và hiểu một thuật toán cho nó là một dấu hiệu cho thấy bạn có mối quan tâm và hiểu biết khá sâu sắc về các thuật toán này. Ngay cả khi bạn chưa nghiên cứu thuật toán GC của Java, nó sẽ gây ấn tượng với tôi nếu ai đó có thể đưa ra một mô tả hợp lý về cấu trúc dữ liệu và thuật toán sẽ được sử dụng.

Với tư cách là một lập trình viên Java, sẽ tốt hơn nếu nhà phát triển có thể mô tả các ưu điểm và nhược điểm của GC, bao gồm một chút kiến ​​thức về cách nó được triển khai. Điều này cho thấy có hứng thú với cách các công cụ bạn sử dụng hoạt động thay vì chỉ sử dụng chúng một cách thụ động. Biết các chi phí cũng sẽ giúp bạn lập trình theo cách giảm thiểu chi phí.

Tôi sẽ không nói đây là "kiến thức bắt buộc" để kiếm sống như một nhà phát triển Java, nhưng một kỹ năng cộng thêm cho thấy bạn có thể và sẵn sàng đi sâu hơn một chút so với những gì bạn cần biết để hoàn thành công việc hôm nay.


2
Biết một sự hiểu biết cơ bản tôi sẽ đồng ý (hiểu những điều làm cho bạn trở thành một lập trình viên tốt hơn). Vấn đề là nếu bạn biết các chi tiết phức tạp và sau đó use that informationđể thiết kế mã của bạn. Điều này có thể gây ra vấn đề vì GC được cải thiện và các giả định của bạn về cách thức GC không còn giữ và mã trở nên không tối ưu (và trong trường hợp xấu nhất có thể cản trở GC). Điều tốt để biết, nhưng bạn nên thiết kế mã của mình bằng cách sử dụng các thực tiễn tốt nhất không phải với một triển khai cụ thể trong tâm trí; trình biên dịch và GC luôn được cải thiện và tối ưu hóa vĩ mô cuối cùng sẽ không hữu ích.
Martin York

Tôi đã suy nghĩ nhiều hơn rằng nếu bạn biết điều gì đó về cách Stringtriển khai, thì bạn sẽ không nối vào một chuỗi bằng cách sử dụng +trong một vòng lặp.
JohnMcG

4

Tôi thấy hai lý do tại sao người ta nên biết cách thức thu gom rác (hoặc bất kỳ thuật toán / công nghệ) nào hoạt động. Đây là:
1. Bạn có được kiến ​​thức tốt hơn về những gì đang diễn ra bên dưới mã bạn viết. Điều này thường có thể giúp bạn viết mã hiệu quả hơn, điều này sẽ đảm bảo hiệu suất tốt hơn. Trong một số trường hợp, điều này có thể rất quan trọng. (Tôi đã có một trải nghiệm khó chịu khi GWT dựa vào trình thu gom rác của trình duyệt và chúng tôi đã bị rò rỉ bộ nhớ rất lớn với Chrome. Vì vậy, chúng tôi phải xem chính xác điều gì đã gây ra rò rỉ.)
2. Các thuật toán như vậy luôn luôn (hoặc gần như luôn luôn, không, luôn luôn) đáng tin cậy cho các nhà phát triển thông minh, lành nghề, có trình độ và kinh nghiệm. Vì vậy, nghiên cứu phương pháp của họ có thể rất hữu ích.

Tôi thấy một lý do khác tại sao bạn được hỏi câu hỏi như vậy tại cuộc phỏng vấn. Một số nhà phát triển (đặc biệt là đồng nghiệp cũ của tôi) nghĩ rằng nhà phát triển không đủ thông minh hoặc chăm chỉ, nếu anh ấy / cô ấy không biết những điều đó. Tôi không đồng ý với tuyên bố này. Nhưng dù sao, biết những điều như vậy là một cách tốt để gây ấn tượng với người phỏng vấn của bạn.


1
Tôi đồng ý với (2) và một nửa (1) (giúp gỡ lỗi). Nhưng có những nguy hiểm trong (1) và thiết kế mã của bạn để hoạt động với một triển khai cụ thể của một GC ở chỗ nó sẽ không còn tối ưu khi một trong hai GC được cải thiện hoặc bạn chuyển sang thực hiện với một loại GC khác.
Martin York

@Loki Astari, bạn nói đúng về việc nó nguy hiểm cho việc triển khai cụ thể. Tuy nhiên, mặt khác, có những thứ không thay đổi (ít nhất là trong một thời gian dài), ví dụ, các nguyên tắc thu gom rác của .NET.
superM

@superM: Thật ra, GC của Mono khác biệt đáng kể so với Microsoft và đang trong quá trình thay thế bằng một cái khác hoàn toàn khác.
Jörg W Mittag

@superM: Không có vẻ là sự phát triển chậm của Java đối với tôi: en.wikipedia.org/wiki/Java_version_history (hình như mỗi năm một lần có một bản vá hoặc cập nhật mới). Với một phiên bản mới vào năm tới. Bây giờ điều đó không có nghĩa là GC được cập nhật mỗi lần nhưng cho thấy tiềm năng của nó.
Martin York

@Loki Astari, đúng vậy. Rất nhiều trong việc phát triển phần mềm liên tục thay đổi nhanh chóng, và công việc của chúng tôi là theo kịp nó. Ngoài ra, tất cả các thay đổi đều dựa trên những gì đã có, vì vậy tôi sẽ không mong đợi bất kỳ thay đổi căn bản nào trong 1 hoặc 2 phiên bản.
superM

4

Bạn nên biết về bộ sưu tập rác thế hệ và các chi tiết cụ thể về bộ sưu tập rác Java (các không gian PermGen, Eden và Tenured). Bạn cũng nên làm quen với việc thu gom rác nói chung (như tại sao việc đếm tham chiếu thường là một ý tưởng tồi và tại sao đánh dấu và quét lại tốt hơn). Tôi cũng khuyên bạn nên đọc một số triển khai thay thế (như GC "tạm dừng" trong Zing JVM của Azul và dự án Metronome thời gian thực của IBM ).


3

Bạn nên có MỘT SỐ kiến ​​thức về cách bộ sưu tập rác cho Java hoạt động vì hai lý do:

Đầu tiên, nếu bạn không biết nó hoạt động như thế nào, thì bạn có thể vô tình đưa ra các quyết định thiết kế dẫn đến hiệu suất trong trường hợp xấu nhất trong ứng dụng thực tế của bạn. Điều này sẽ ngày càng ít xảy ra khi GC cải thiện, nhưng nếu bạn có lựa chọn thuật toán trong ứng dụng của mình, thì việc biết một số điều về GC có nghĩa là bạn có thể chọn một kiến ​​thức về những gì nó sẽ làm, thay vì tìm hiểu rằng nó gây ra hành vi xấu.

Thứ hai, nếu bạn không biết nó hoạt động như thế nào, bạn có thể điều chỉnh GC cho một ứng dụng nhất định. Hầu hết các lập trình viên Java không bao giờ cần điều chỉnh GC, vì các tham số mặc định hoạt động đủ tốt hầu hết thời gian. Nếu bạn làm điều gì đó vượt ra khỏi 'phần lớn thời gian', thì bạn có thể thấy mình điều chỉnh các tham số GC. Làm như vậy mà không có kiến ​​thức về GC chỉ là các nút xoay ngẫu nhiên - bạn có thể nhận được thứ gì đó hữu ích từ nó, nhưng nhiều khả năng bạn sẽ khiến mọi thứ trở nên tồi tệ hơn.

Vì vậy, trong khi tôi không mong đợi một lập trình viên Java giỏi biết mọi thứ dưới ánh mặt trời về GC, tôi hy vọng rằng lập trình viên đó sẽ biết ở mức độ nào đó, GC trong JVM họ đang sử dụng các hàm và sự đánh đổi là gì cho điều đó Thuật toán GC.


1

Đúng, mọi nhà phát triển Java chắc chắn nên biết những gì đang diễn ra đằng sau hậu trường của máy ảo và bao gồm cả công việc của bộ sưu tập rác.

Mức độ của howver kiến ​​thức là một câu hỏi khác. Tôi sẽ không mong đợi một nhà phát triển bình thường giải thích sự khác biệt của việc triển khai thực tế (tôi sẽ phải tự mình thực hiện một số nghiên cứu về điều đó) tuy nhiên nguyên tắc cơ bản của việc một GC làm và những ưu và nhược điểm đối với việc quản lý bộ nhớ là gì thông thoáng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.