Tại sao các ngôn ngữ như C và C ++ không có bộ sưu tập rác, trong khi Java thì có? [đóng cửa]

Chà, tôi biết rằng có những thứ như malloc / miễn phí cho C và new / use-a-killer để quản lý bộ nhớ trong C ++, nhưng tôi đã tự hỏi tại sao không có "cập nhật mới" cho các ngôn ngữ này cho phép người dùng có tùy chọn để quản lý bộ nhớ theo cách thủ công hoặc để hệ thống tự động thực hiện (bộ sưu tập rác) không?

Một phần của câu hỏi newb-ish, nhưng chỉ ở trong CS khoảng một năm.

Thu gom rác yêu cầu cấu trúc dữ liệu để theo dõi phân bổ và / hoặc đếm tham chiếu. Chúng tạo ra chi phí bộ nhớ, hiệu suất và độ phức tạp của ngôn ngữ. C ++ được thiết kế để "gần với kim loại", nói cách khác, nó có mặt hiệu suất cao hơn của sự đánh đổi so với các tính năng tiện lợi. Các ngôn ngữ khác làm cho sự đánh đổi đó khác nhau. Đây là một trong những cân nhắc trong việc lựa chọn một ngôn ngữ, mà bạn thích nhấn mạnh.

Điều đó nói rằng, có rất nhiều lược đồ để đếm tham chiếu trong C ++ khá nhẹ và hiệu quả, nhưng chúng nằm trong các thư viện, cả thương mại và nguồn mở, chứ không phải là một phần của ngôn ngữ. Việc đếm tham chiếu để quản lý tuổi thọ đối tượng không giống như thu gom rác, nhưng nó giải quyết nhiều vấn đề tương tự và phù hợp hơn với cách tiếp cận cơ bản của C ++.

Nói đúng ra, không có quản lý bộ nhớ nào trong ngôn ngữ C. malloc () và free () không phải là từ khóa trong ngôn ngữ, mà chỉ là các hàm được gọi từ thư viện. Sự khác biệt này có thể là mô phạm bây giờ, bởi vì malloc () và free () là một phần của thư viện chuẩn C và sẽ được cung cấp bởi bất kỳ triển khai tuân thủ tiêu chuẩn nào của C, nhưng điều này không phải lúc nào cũng đúng.

Tại sao bạn muốn có một ngôn ngữ không có tiêu chuẩn để quản lý bộ nhớ? Điều này quay trở lại nguồn gốc của C là 'lắp ráp di động'. Có nhiều trường hợp phần cứng và thuật toán có thể được hưởng lợi từ, hoặc thậm chí yêu cầu, các kỹ thuật quản lý bộ nhớ chuyên dụng. Theo như tôi biết, không có cách nào để vô hiệu hóa hoàn toàn việc quản lý bộ nhớ riêng của Java và thay thế nó bằng chính bạn. Điều này chỉ đơn giản là không được chấp nhận trong một số tình huống hiệu suất cao / tài nguyên tối thiểu. C cung cấp sự linh hoạt gần như hoàn chỉnh để chọn chính xác cơ sở hạ tầng mà chương trình của bạn sẽ sử dụng. Cái giá phải trả là ngôn ngữ C cung cấp rất ít trợ giúp trong việc viết mã chính xác, không có lỗi.

Câu trả lời thực sự là cách duy nhất để tạo ra một cơ chế thu gom rác an toàn, hiệu quả là có sự hỗ trợ ở cấp độ ngôn ngữ cho các tài liệu tham khảo mờ. (Hoặc, ngược lại, thiếu hỗ trợ ở cấp độ ngôn ngữ để thao tác bộ nhớ trực tiếp.)

Java và C # có thể làm điều đó bởi vì chúng có các kiểu tham chiếu đặc biệt không thể thao tác được. Điều này cho phép bộ thực thi tự do thực hiện những việc như di chuyển các đối tượng được phân bổ trong bộ nhớ , điều này rất quan trọng đối với việc thực hiện GC hiệu suất cao.

Đối với hồ sơ, không có triển khai GC hiện đại nào sử dụng tính tham chiếu , do đó hoàn toàn là cá trích đỏ. Các GC hiện đại sử dụng bộ sưu tập thế hệ, trong đó các phân bổ mới được xử lý về cơ bản giống như cách phân bổ ngăn xếp trong một ngôn ngữ như C ++, và sau đó định kỳ mọi đối tượng mới được phân bổ vẫn còn sống được chuyển đến một không gian "sống sót" riêng biệt và toàn bộ một thế hệ của các đối tượng được giải quyết cùng một lúc.

Cách tiếp cận này có những ưu và nhược điểm: nhược điểm là phân bổ heap trong ngôn ngữ hỗ trợ GC nhanh như phân bổ stack trong ngôn ngữ không hỗ trợ GC và nhược điểm là các đối tượng cần thực hiện dọn dẹp trước khi bị phá hủy yêu cầu một cơ chế riêng (ví dụ: usingtừ khóa của C # ) hoặc nếu không, mã dọn dẹp của họ chạy không xác định.

Lưu ý rằng một chìa khóa cho một GC hiệu suất cao là phải có hỗ trợ ngôn ngữ cho một lớp tài liệu tham khảo đặc biệt. C không có hỗ trợ ngôn ngữ này và sẽ không bao giờ; bởi vì C ++ có quá tải toán tử, nó có thể mô phỏng loại con trỏ của GC, mặc dù nó sẽ phải được thực hiện cẩn thận. Trên thực tế, khi Microsoft phát minh ra phương ngữ C ++ chạy theo CLR (thời gian chạy .NET), họ đã phải phát minh ra một cú pháp mới cho "tham chiếu kiểu C #" (ví dụ Foo^) để phân biệt với "tham chiếu kiểu C ++" (ví dụ Foo&).

Những gì C ++ có, và những gì được lập trình viên C ++ sử dụng thường xuyên, là những con trỏ thông minh , thực sự chỉ là một cơ chế đếm tham chiếu. Tôi sẽ không coi việc tham chiếu là GC "thật", nhưng nó mang lại nhiều lợi ích giống nhau, với chi phí hiệu năng chậm hơn so với quản lý bộ nhớ thủ công hoặc GC thực sự, nhưng với lợi thế là phá hủy xác định.

Vào cuối ngày, câu trả lời thực sự sôi nổi với một tính năng thiết kế ngôn ngữ. C đã đưa ra một lựa chọn, C ++ đã đưa ra một lựa chọn cho phép nó tương thích ngược với C trong khi vẫn cung cấp các lựa chọn thay thế đủ tốt cho hầu hết các mục đích và Java và C # đã đưa ra một lựa chọn khác không tương thích với C nhưng cũng đủ tốt cho hầu hết các mục đích. Thật không may, không có viên đạn bạc, nhưng làm quen với các lựa chọn khác nhau ngoài kia sẽ giúp bạn chọn đúng cho bất kỳ chương trình nào bạn đang cố gắng xây dựng.

Bởi vì, khi sử dụng sức mạnh của C ++, không có nhu cầu.

Herb Sutter: " Tôi đã không xóa văn bản trong nhiều năm. "

xem Viết mã C ++ hiện đại: C ++ đã phát triển như thế nào trong những năm 21:10

Nó có thể gây ngạc nhiên cho nhiều lập trình viên C ++ có kinh nghiệm.

"Tất cả" một trình thu gom rác là một quá trình chạy kiểm tra định kỳ để xem liệu có bất kỳ đối tượng không được ước tính nào trong bộ nhớ và nếu có xóa chúng. (Vâng, tôi biết đây là một sự đơn giản hóa quá mức). Đây không phải là một tài sản của ngôn ngữ, mà là khuôn khổ.

Có người thu gom rác bằng văn bản cho C và C ++ - điều này một ví dụ.

Một lý do tại sao một người chưa được "thêm" vào ngôn ngữ có thể là do khối lượng mã hiện tại sẽ không bao giờ sử dụng vì họ sử dụng mã riêng để quản lý bộ nhớ. Một lý do khác có thể là các loại ứng dụng được viết bằng C và C ++ không cần chi phí liên quan đến quy trình thu gom rác.

C được thiết kế trong thời đại mà bộ sưu tập rác hầu như không phải là một lựa chọn. Nó cũng được thiết kế để sử dụng trong đó bộ sưu tập rác thường không hoạt động - kim loại trần, môi trường thời gian thực với bộ nhớ tối thiểu và hỗ trợ thời gian chạy tối thiểu. Hãy nhớ rằng C là ngôn ngữ thực hiện cho unix đầu tiên, chạy trên pdp-11 với bộ nhớ 64 * K *. C ++ ban đầu là một phần mở rộng của C - sự lựa chọn đã được thực hiện và rất khó để ghép bộ sưu tập rác vào một ngôn ngữ hiện có. Đó là loại thứ phải được xây dựng từ tầng trệt.

Tôi không có trích dẫn chính xác nhưng cả Bjarne và Herb Sutter đều nói điều gì đó dọc theo dòng:

C ++ không cần bộ thu gom rác, vì nó không có rác.

Trong C ++ hiện đại, bạn sử dụng con trỏ thông minh và do đó không có rác.

Bạn hỏi tại sao những ngôn ngữ này chưa được cập nhật để bao gồm một trình thu gom rác tùy chọn.

Vấn đề với bộ sưu tập rác tùy chọn là bạn không thể trộn mã sử dụng các mô hình khác nhau. Đó là, nếu tôi viết mã giả sử bạn đang sử dụng trình thu gom rác, bạn không thể sử dụng nó trong chương trình đã tắt bộ sưu tập rác. Nếu bạn làm thế, nó sẽ bị rò rỉ ở mọi nơi.

Bạn có thể tưởng tượng việc viết một trình xử lý thiết bị bằng ngôn ngữ với bộ sưu tập rác không? Có bao nhiêu bit có thể đi xuống dòng trong khi GC đang chạy?

Hay một hệ điều hành? Làm thế nào bạn có thể bắt đầu bộ sưu tập rác chạy trước khi bạn khởi động kernel?

C được thiết kế cho mức độ thấp gần với các tác vụ phần cứng. Vấn đề? Là một ngôn ngữ tốt đến nỗi nó cũng là một lựa chọn tốt cho nhiều nhiệm vụ cấp cao hơn. Các czars ngôn ngữ nhận thức được những sử dụng này nhưng họ cần hỗ trợ các yêu cầu của trình điều khiển thiết bị, mã nhúng và hệ điều hành là ưu tiên.

Câu trả lời ngắn gọn và nhàm chán cho câu hỏi này là cần phải có một ngôn ngữ không được thu gom rác ngoài kia cho những người viết công cụ thu gom rác. Về mặt khái niệm không dễ để có một ngôn ngữ đồng thời cho phép kiểm soát rất chính xác bố cục bộ nhớ và có một GC chạy trên đầu.

Câu hỏi khác là tại sao C và C ++ không có người thu gom rác. Chà, tôi biết C ++ có một vài người trong số họ nhưng họ không thực sự nổi tiếng vì họ buộc phải đối phó với một ngôn ngữ không được thiết kế để trở thành GC-ed ngay từ đầu và những người vẫn sử dụng C ++ trong tuổi này không thực sự là loại bỏ lỡ một GC.

Ngoài ra, thay vì thêm GC vào ngôn ngữ không phải là ngôn ngữ cũ, việc tạo một ngôn ngữ mới có hầu hết các cú pháp tương tự trong khi hỗ trợ một ngôn ngữ thực sự dễ dàng hơn. Java và C # là những ví dụ tốt về điều này.

Có nhiều vấn đề khác nhau, bao gồm ...

• Mặc dù GC được phát minh trước C ++ và có thể trước C, cả C và C ++ đều được triển khai trước khi các GC được chấp nhận rộng rãi như là thực tế.
• Bạn không thể dễ dàng thực hiện một ngôn ngữ và nền tảng GC mà không có ngôn ngữ không phải là GC cơ bản.
• Mặc dù GC hiệu quả hơn nhiều so với không phải là GC đối với mã ứng dụng điển hình được phát triển trong thời gian điển hình, v.v., có những vấn đề mà nỗ lực phát triển nhiều hơn là sự đánh đổi tốt và quản lý bộ nhớ chuyên biệt sẽ vượt trội so với GC có mục đích chung. Bên cạnh đó, C ++ thường hiệu quả hơn nhiều so với hầu hết các ngôn ngữ GC ngay cả khi không có bất kỳ nỗ lực phát triển bổ sung nào.
• GC không an toàn hơn so với RAII kiểu C ++. RAII cho phép các tài nguyên khác ngoài bộ nhớ được tự động dọn sạch, về cơ bản vì nó hỗ trợ các công cụ phá hủy đáng tin cậy và kịp thời. Chúng không thể được kết hợp với các phương pháp GC thông thường vì các vấn đề với chu kỳ tham chiếu.
• Các ngôn ngữ GC có các loại rò rỉ bộ nhớ đặc trưng của riêng chúng, đặc biệt liên quan đến bộ nhớ sẽ không bao giờ được sử dụng lại, nhưng ở đó các tham chiếu hiện có tồn tại chưa bao giờ bị loại bỏ hoặc ghi đè. Sự cần thiết phải làm điều này một cách rõ ràng về nguyên tắc không khác gì so với nhu cầu deletehoặc freerõ ràng. Cách tiếp cận GC vẫn có một lợi thế - không có tham chiếu lơ lửng - và phân tích tĩnh có thể bắt được một số trường hợp, nhưng một lần nữa, không có một giải pháp hoàn hảo nào cho tất cả các trường hợp.

Về cơ bản, một phần là về tuổi của các ngôn ngữ, nhưng sẽ luôn có một nơi dành cho các ngôn ngữ không phải là GC - ngay cả khi đó là một chút của một nơi không có gì đó. Và nghiêm túc, trong C ++, việc thiếu GC không phải là vấn đề lớn - bộ nhớ của bạn được quản lý khác nhau, nhưng nó không được quản lý.

Microsofts được quản lý C ++ có ít nhất một số khả năng kết hợp giữa GC và không phải GC trong cùng một ứng dụng, cho phép kết hợp các lợi thế của từng loại, nhưng tôi không có kinh nghiệm để nói rằng điều này hoạt động tốt như thế nào trong thực tế.

Liên kết lại liên kết đến câu trả lời liên quan của tôi ...

• https://stackoverflow.com/questions/1529679/how-do-you-program-safely-outside-of-a-managed-code-en môi / 1529731 # 1529731
• https://stackoverflow.com/questions/1424660/garbage-collection-vs-non-garbage-collection-programming-lacular/1496547#1496547
• https://stackoverflow.com/questions/4984849/why-circular-referenced-objects-with-del-dposed-are-uncollectable-in-python/4984934#4984934
• https://stackoverflow.com/questions/5009869/how-to-im vây-garbage-collection-in-c / 5009984 # 5009984

Bộ sưu tập rác về cơ bản không tương thích với ngôn ngữ hệ thống được sử dụng để phát triển trình điều khiển cho phần cứng có khả năng DMA.

Hoàn toàn có khả năng con trỏ duy nhất đến một đối tượng sẽ được lưu trữ trong một thanh ghi phần cứng ở một số thiết bị ngoại vi. Vì người thu gom rác sẽ không biết về điều này, nên nó sẽ nghĩ rằng đối tượng không thể truy cập được và thu thập nó.

Đối số này giữ gấp đôi để nén GC. Ngay cả khi bạn cẩn thận duy trì các tham chiếu trong bộ nhớ đến các đối tượng được sử dụng bởi các thiết bị ngoại vi phần cứng, khi GC di chuyển đối tượng, nó sẽ không biết cách cập nhật con trỏ có trong thanh ghi cấu hình ngoại vi.

Vì vậy, bây giờ bạn cần một hỗn hợp bộ đệm DMA bất động và các đối tượng được quản lý bởi GC, có nghĩa là bạn có tất cả các nhược điểm của cả hai.

Bởi vì, C & C ++ là các ngôn ngữ cấp độ tương đối thấp dành cho mục đích chung, thậm chí, ví dụ, để chạy trên bộ xử lý 16 bit với 1 MB bộ nhớ trong một hệ thống nhúng, không thể lãng phí bộ nhớ với gc.

Có các trình thu gom rác trong C ++ và C. Không chắc cách thức hoạt động trong C, nhưng trong C ++, bạn có thể tận dụng RTTI để tự động khám phá biểu đồ đối tượng của mình và sử dụng biểu đồ đó để thu gom rác.

Theo hiểu biết của tôi, bạn không thể viết Java mà không có trình thu gom rác. Một tìm kiếm nhỏ bật lên này .

Sự khác biệt chính giữa Java và C / C ++ là trong C / C ++, sự lựa chọn luôn là của bạn, trong khi ở Java, bạn thường không có các tùy chọn theo thiết kế.

Đó là một sự đánh đổi giữa hiệu suất và an toàn.

Không có gì đảm bảo rằng rác của bạn sẽ được thu thập trong Java, do đó, nó có thể bị treo xung quanh khi sử dụng hết dung lượng trong một thời gian dài, trong khi việc quét các đối tượng không được ước tính (ví dụ như rác) cũng mất nhiều thời gian hơn so với việc xóa hoặc giải phóng rõ ràng một đối tượng không sử dụng.

Tất nhiên, ưu điểm là người ta có thể xây dựng một ngôn ngữ mà không có con trỏ hoặc không bị rò rỉ bộ nhớ, do đó, một người có nhiều khả năng tạo ra mã chính xác.

Đôi khi có thể có một chút "tôn giáo" đối với những cuộc tranh luận này - được cảnh báo!

Dưới đây là danh sách các vấn đề cố hữu của GC, khiến nó không sử dụng được trong ngôn ngữ hệ thống như C:

• GC phải chạy dưới mức mã mà các đối tượng mà nó quản lý. Đơn giản là không có mức như vậy trong kernel.

• Thỉnh thoảng, một GC phải dừng mã được quản lý. Bây giờ hãy nghĩ về những gì sẽ xảy ra nếu nó làm điều đó với kernel của bạn. Tất cả quá trình xử lý trên máy của bạn sẽ dừng lại trong khoảng một phần nghìn giây trong khi GC quét tất cả các cấp phát bộ nhớ hiện có. Điều này sẽ giết chết mọi nỗ lực để tạo ra các hệ thống hoạt động theo các yêu cầu nghiêm ngặt theo thời gian thực.

• Một GC cần có khả năng phân biệt giữa con trỏ và con trỏ. Đó là, nó phải có khả năng nhìn vào mọi đối tượng bộ nhớ tồn tại và có thể tạo ra một danh sách các điểm bù nơi con trỏ của nó có thể được tìm thấy.

  Khám phá này phải hoàn hảo: GC phải có khả năng đuổi theo tất cả các con trỏ mà nó khám phá. Nếu nó được xác định là dương tính giả, nó có thể sẽ sụp đổ. Nếu không phát hiện ra âm tính giả, nó có thể sẽ phá hủy một đối tượng vẫn đang sử dụng, làm hỏng mã được quản lý hoặc âm thầm làm hỏng dữ liệu của nó.

  Điều này hoàn toàn đòi hỏi thông tin loại được lưu trữ trong mọi đối tượng tồn tại. Tuy nhiên, cả C và C ++ đều cho phép các đối tượng dữ liệu cũ đơn giản không chứa thông tin loại.

• GC là một doanh nghiệp vốn đã chậm. Các lập trình viên đã được xã hội hóa với Java có thể không nhận ra điều này, nhưng các chương trình có thể là các đơn đặt hàng có cường độ nhanh hơn khi chúng không được triển khai trong Java. Và một trong những yếu tố khiến Java chậm là GC. Đây là những gì ngăn cản các ngôn ngữ được phân loại như Java được sử dụng trong siêu máy tính. Nếu máy của bạn tiêu tốn một triệu mỗi năm tiền điện, bạn không muốn trả thậm chí 10% số tiền đó cho việc thu gom rác.

C và C ++ là các ngôn ngữ được tạo để hỗ trợ tất cả các trường hợp sử dụng có thể. Và, như bạn thấy, nhiều trường hợp sử dụng bị loại trừ bởi bộ sưu tập rác. Vì vậy, để hỗ trợ các trường hợp sử dụng này, C / C ++ không thể được thu gom rác.