Chúng ta có nên tránh việc tạo đối tượng trong Java không?

Tôi đã được một đồng nghiệp nói rằng trong việc tạo đối tượng Java là thao tác đắt nhất bạn có thể thực hiện. Vì vậy, tôi chỉ có thể kết luận để tạo ra càng ít đối tượng càng tốt.

Điều này dường như phần nào để đánh bại mục đích của lập trình hướng đối tượng. Nếu chúng ta không tạo đối tượng thì chúng ta chỉ đang viết một kiểu lớp C dài, để tối ưu hóa?

Đồng nghiệp của bạn không biết họ đang nói về cái gì.

Hoạt động đắt tiền nhất của bạn sẽ được lắng nghe họ . Họ đã lãng phí thời gian của bạn để hướng bạn đến thông tin đã lỗi thời hơn một thập kỷ (kể từ ngày ban đầu câu trả lời này được đăng) cũng như bạn phải dành thời gian đăng lên đây và nghiên cứu về sự thật.

Hy vọng rằng họ chỉ đang thờ ơ với những gì họ nghe hoặc đọc từ hơn một thập kỷ trước và không biết gì hơn. Tôi cũng sẽ lấy bất cứ điều gì khác mà họ nói là nghi ngờ, đây sẽ là một lời ngụy biện nổi tiếng bởi bất cứ ai luôn cập nhật theo bất kỳ cách nào.

Tất cả mọi thứ là một đối tượng (ngoại trừ primitives)

Mọi thứ khác ngoài nguyên thủy ( int, long, double, v.v.) đều là các Đối tượng trong Java. Không có cách nào để tránh việc tạo Object trong Java.

Việc tạo đối tượng trong Java do các chiến lược phân bổ bộ nhớ của nó nhanh hơn C ++ trong hầu hết các trường hợp và cho tất cả các mục đích thực tế so với mọi thứ khác trong JVM có thể được coi là "miễn phí" .

Ngay từ cuối những năm 1990, các triển khai JVM đã có một số chi phí hoạt động trong việc phân bổ các Đối tượng thực tế. Điều này đã không xảy ra kể từ ít nhất là năm 2005.

Nếu bạn điều chỉnh -Xmsđể hỗ trợ tất cả bộ nhớ bạn cần để ứng dụng của bạn chạy chính xác, thì GC có thể không bao giờ phải chạy và quét hầu hết rác trong các triển khai GC hiện đại, các chương trình có thời gian ngắn có thể không bao giờ là GC.

Nó không thử và tối đa hóa không gian trống, dù sao đó là cá trích đỏ, nó tối đa hóa hiệu suất của thời gian chạy. Nếu điều đó có nghĩa là Heap JVM được phân bổ gần như 100% mọi lúc, thì cũng vậy. Bộ nhớ heap JVM miễn phí không cung cấp cho bạn bất cứ điều gì chỉ cần ngồi ở đó.

Có một quan niệm sai lầm rằng GC sẽ giải phóng bộ nhớ trở lại phần còn lại của hệ thống một cách hữu ích, điều này là hoàn toàn sai!

Heap JVM không phát triển và co lại để phần còn lại của hệ thống bị ảnh hưởng tích cực bởi bộ nhớ trống trong HVM JVM . -Xmsphân bổ TẤT CẢ những gì được chỉ định khi khởi động và heuristic của nó là không bao giờ thực sự giải phóng bất kỳ bộ nhớ nào đó trở lại HĐH để được chia sẻ với bất kỳ quy trình HĐH nào khác cho đến khi phiên bản JVM đó thoát hoàn toàn. -Xms=1GB -Xmx=1GBphân bổ 1GB RAM bất kể có bao nhiêu đối tượng thực sự được tạo tại bất kỳ thời điểm nào. Có một số cài đặt cho phép phát hành phần trăm bộ nhớ heap, nhưng với tất cả các mục đích thực tế , JVM không bao giờ có thể giải phóng đủ bộ nhớ này để điều này xảy rado đó, không có quá trình nào khác có thể lấy lại bộ nhớ này, vì vậy phần còn lại của hệ thống không được hưởng lợi từ Heap JVM là miễn phí. Một RFE cho điều này đã được "chấp nhận" 29-NOV-2006, nhưng chưa có gì được thực hiện về nó. Đây là hành vi không được coi là mối quan tâm của bất cứ ai có thẩm quyền.

Có một quan niệm sai lầm rằng việc tạo ra nhiều đối tượng tồn tại nhỏ khiến JVM tạm dừng trong thời gian dài, điều này cũng sai.

Các thuật toán GC hiện tại thực sự được tối ưu hóa để tạo ra nhiều đối tượng nhỏ tồn tại trong thời gian ngắn, về cơ bản là heuristic 99% cho các đối tượng Java trong mọi chương trình. Các nỗ lực tại Object Pooling thực sự sẽ làm cho JVM hoạt động kém hơn trong hầu hết các trường hợp.

Các đối tượng duy nhất cần gộp ngày hôm nay là các Đối tượng tham chiếu đến các tài nguyên hữu hạn bên ngoài JVM; Ổ cắm, tệp, kết nối cơ sở dữ liệu, vv và có thể được sử dụng lại. Các đối tượng thông thường không thể được gộp chung theo nghĩa như trong các ngôn ngữ cho phép bạn truy cập trực tiếp vào các vị trí bộ nhớ. Bộ nhớ đệm đối tượng là một khái niệm khác nhau và có thể hoặc không phải là thứ mà một số người ngây thơ gọi là gộp chung , hai khái niệm này không giống nhau và không nên bị lẫn lộn.

Các thuật toán GC hiện đại không gặp phải vấn đề này bởi vì chúng không phân bổ theo lịch trình, chúng sẽ phân bổ khi cần bộ nhớ trống trong một thế hệ nhất định. Nếu heap đủ lớn, thì không có sự thỏa thuận nào xảy ra đủ lâu để gây ra bất kỳ tạm dừng nào.

Các ngôn ngữ động hướng đối tượng đang đánh bại C ngay cả ngày nay trong các bài kiểm tra nhạy cảm.

Điểm mấu chốt: Đừng thỏa hiệp thiết kế của bạn để có các phím tắt tạo đối tượng. Tránh tạo các đối tượng không cần thiết. Nếu hợp lý, thiết kế để tránh các hoạt động dư thừa (dưới bất kỳ hình thức nào).

Trái với hầu hết các câu trả lời - có, phân bổ đối tượng DOES có chi phí liên quan. Đó là một chi phí thấp, nhưng bạn nên tránh tạo ra các đối tượng không cần thiết. Tương tự như bạn nên tránh bất cứ điều gì không cần thiết trong mã của bạn. Biểu đồ đối tượng lớn làm cho GC chậm hơn, ngụ ý thời gian thực hiện lâu hơn trong đó bạn có thể sẽ có nhiều cuộc gọi phương thức hơn, kích hoạt nhiều lỗi bộ nhớ cache CPU hơn và tăng khả năng quá trình của bạn bị hoán đổi vào đĩa trong trường hợp RAM thấp.

Trước khi bất kỳ ai muốn nói về trường hợp này - tôi đã lập hồ sơ các ứng dụng, trước khi tối ưu hóa, đã tạo ra hơn 20 MB đối tượng để xử lý ~ 50 hàng dữ liệu. Điều này là tốt trong thử nghiệm, cho đến khi bạn mở rộng tới một trăm yêu cầu một phút và đột nhiên bạn đang tạo ra 2GB dữ liệu mỗi phút. Nếu bạn muốn thực hiện 20 reqs / giây, bạn đang tạo 400MB đối tượng và sau đó ném nó đi. 20 reqs / giây là rất nhỏ đối với một máy chủ phong nha.

Trên thực tế, do các chiến lược quản lý bộ nhớ mà ngôn ngữ Java (hoặc bất kỳ ngôn ngữ được quản lý nào khác) tạo ra có thể, việc tạo đối tượng ít hơn nhiều so với việc tăng một con trỏ trong một khối bộ nhớ được gọi là thế hệ trẻ. Nó nhanh hơn nhiều so với C, trong đó việc tìm kiếm bộ nhớ trống phải được thực hiện.

Phần khác của chi phí là phá hủy đối tượng, nhưng thật khó để so sánh với C. Chi phí của một bộ sưu tập dựa trên số lượng đối tượng được lưu trong thời gian dài nhưng tần suất của các bộ sưu tập dựa trên số lượng đối tượng được tạo ... trong cuối cùng, nó vẫn nhanh hơn nhiều so với quản lý bộ nhớ kiểu C.

Các áp phích khác đã chỉ ra một cách đúng đắn rằng việc tạo đối tượng cực kỳ nhanh trong Java và bạn thường không nên lo lắng về nó trong bất kỳ ứng dụng Java thông thường nào.

Có một vài tình huống rất đặc biệt là một ý tưởng tốt để tránh tạo đối tượng.

• Khi bạn đang viết một ứng dụng nhạy cảm với độ trễ và muốn tránh tạm dừng GC. Bạn càng tạo ra nhiều đối tượng, càng nhiều GC xảy ra và cơ hội tạm dừng càng lớn. Đây có thể là một sự cân nhắc hợp lệ cho các trò chơi, một số ứng dụng phương tiện, điều khiển robot, giao dịch tần số cao, v.v ... Giải pháp là phân bổ trước tất cả các đối tượng / mảng bạn cần lên trước và sử dụng lại chúng. Có những thư viện chuyên cung cấp loại khả năng này, ví dụ Javolution . Nhưng có thể nói, nếu bạn thực sự quan tâm đến độ trễ thấp, bạn nên sử dụng C / C ++ / trình biên dịch thay vì Java hoặc C # :-)
• Tránh các nguyên thủy đóng hộp (Double, Integer, v.v.) có thể là một tối ưu hóa vi mô rất có lợi trong một số trường hợp nhất định. Do các nguyên hàm không được đóng hộp (double, int, v.v.) tránh được chi phí cho mỗi đối tượng, nên chúng hoạt động chuyên sâu với CPU nhanh hơn nhiều như xử lý số, v.v. Thông thường, các mảng nguyên thủy hoạt động rất tốt trong Java, vì vậy bạn muốn sử dụng chúng cho việc bẻ khóa số của mình thay vì bất kỳ loại đối tượng khác.
• Trong các tình huống bộ nhớ bị ràng buộc, bạn muốn giảm thiểu số lượng đối tượng (hoạt động) được tạo do mỗi đối tượng mang một chi phí nhỏ (thường là 8-16 byte tùy thuộc vào việc thực hiện JVM). Trong những trường hợp như vậy, bạn nên ưu tiên một số lượng nhỏ các đối tượng hoặc mảng lớn để lưu trữ dữ liệu của bạn hơn là một số lượng lớn các đối tượng nhỏ.

Có một hạt nhân của sự thật trong những gì đồng nghiệp của bạn đang nói. Tôi trân trọng đề nghị vấn đề với việc tạo đối tượng thực sự là bộ sưu tập rác . Trong C ++, lập trình viên có thể điều khiển chính xác cách giải quyết bộ nhớ. Chương trình có thể tích lũy crud bao lâu hoặc ngắn tùy thích. Hơn nữa, chương trình C ++ có thể loại bỏ crud bằng cách sử dụng một luồng khác với luồng đã tạo ra nó. Do đó, chủ đề hiện đang làm việc không bao giờ phải dừng lại để làm sạch.

Ngược lại, Máy ảo Java (JVM) định kỳ dừng mã của bạn để lấy lại bộ nhớ không sử dụng. Hầu hết các nhà phát triển Java không bao giờ nhận thấy sự tạm dừng này, vì nó thường không thường xuyên và rất ngắn. Bạn tích lũy càng nhiều hoặc JVM của bạn càng bị ràng buộc, các tạm dừng này càng thường xuyên. Bạn có thể sử dụng các công cụ như VisualVM để trực quan hóa quá trình này.

Trong các phiên bản gần đây của Java, thuật toán thu gom rác (GC) có thể được điều chỉnh . Theo nguyên tắc chung, bạn muốn thực hiện các lần tạm dừng càng ngắn thì chi phí sử dụng trong máy ảo càng đắt (tức là CPU và bộ nhớ dành cho việc điều phối quá trình GC).

Khi nào thì vấn đề này? Bất cứ khi nào bạn quan tâm về tốc độ phản hồi dưới một phần nghìn giây nhất quán, bạn sẽ quan tâm đến GC. Các hệ thống giao dịch tự động được viết bằng Java điều chỉnh JVM rất nhiều để giảm thiểu tạm dừng. Các công ty thường viết Java chuyển sang C ++ trong các tình huống mà các hệ thống phải có khả năng đáp ứng cao mọi lúc.

Đối với hồ sơ, tôi không bỏ qua việc tránh đối tượng nói chung! Mặc định cho lập trình hướng đối tượng. Chỉ điều chỉnh cách tiếp cận này nếu GC cản trở bạn và sau đó chỉ sau khi cố gắng điều chỉnh JVM để tạm dừng ít thời gian hơn. Một cuốn sách hay về điều chỉnh hiệu năng Java là Hiệu suất Java của Charlie Hunt và Binu John.

Có một trường hợp bạn có thể không khuyến khích tạo quá nhiều đối tượng trong Java vì chi phí hoạt động - thiết kế để thực hiện trên nền tảng Android

Ngoài ra, các câu trả lời trên đúng.

GC được điều chỉnh cho nhiều đối tượng sống ngắn

điều đó nói rằng nếu bạn có thể giảm phân bổ đối tượng một cách tầm thường thì bạn nên

một ví dụ sẽ là xây dựng một chuỗi trong một vòng lặp, cách ngây thơ sẽ là

String str = "";
while(someCondition){
    //...
    str+= appendingString;
}

tạo một Stringđối tượng mới trên mỗi +=thao tác (cộng với a StringBuildervà mảng char bên dưới mới)

bạn có thể dễ dàng viết lại thành:

StringBuilder strB = new StringBuilder();
while(someCondition){
    //...
    strB.append(appendingString);
}
String str = strB.toString();

mô hình này (kết quả bất biến và giá trị trung gian có thể thay đổi cục bộ) cũng có thể được áp dụng cho những thứ khác

nhưng khác hơn là bạn nên kéo một hồ sơ để tìm ra nút cổ chai thực sự thay vì đuổi theo ma

Joshua Bloch (một trong những người tạo nền tảng Java) đã viết trong cuốn sách Java hiệu quả vào năm 2001:

Tránh tạo đối tượng bằng cách duy trì nhóm đối tượng của riêng bạn là một ý tưởng tồi trừ khi các đối tượng trong nhóm cực kỳ nặng. Một ví dụ mẫu của một đối tượng thực hiện biện minh cho một nhóm đối tượng là một kết nối cơ sở dữ liệu. Chi phí thiết lập kết nối đủ cao để sử dụng lại các đối tượng này. Tuy nhiên, nói chung, việc duy trì nhóm đối tượng của riêng bạn sẽ làm tăng mã của bạn, tăng dung lượng bộ nhớ và gây hại cho hiệu suất. Các triển khai JVM hiện đại có các trình thu gom rác được tối ưu hóa cao, dễ dàng vượt trội hơn các nhóm đối tượng như vậy trên các đối tượng nhẹ.

Điều này thực sự phụ thuộc vào ứng dụng cụ thể, vì vậy nói chung thực sự rất khó để nói. Tuy nhiên, tôi sẽ khá ngạc nhiên nếu việc tạo đối tượng thực sự là một nút cổ chai hiệu năng trong một ứng dụng. Ngay cả khi chúng chậm, lợi ích kiểu mã có thể sẽ vượt trội hơn hiệu suất (trừ khi nó thực sự đáng chú ý đối với người dùng)

Trong mọi trường hợp, bạn thậm chí không nên bắt đầu lo lắng về những điều này cho đến khi bạn định được mã của mình để xác định các tắc nghẽn hiệu suất thực tế thay vì đoán. Cho đến lúc đó, bạn nên làm bất cứ điều gì tốt nhất cho khả năng đọc mã, không phải hiệu suất.

Tôi nghĩ rằng đồng nghiệp của bạn phải nói từ quan điểm của việc tạo đối tượng không cần thiết. Ý tôi là nếu bạn đang tạo cùng một đối tượng thường xuyên thì tốt hơn là chia sẻ đối tượng đó. Ngay cả trong trường hợp việc tạo đối tượng phức tạp và chiếm nhiều bộ nhớ hơn, bạn có thể muốn sao chép đối tượng đó và tránh tạo quá trình tạo đối tượng phức tạp đó (Nhưng điều đó phụ thuộc vào yêu cầu của bạn). Tôi nghĩ rằng tuyên bố "Tạo đối tượng là tốn kém" nên được đưa vào bối cảnh.

Theo như các yêu cầu về bộ nhớ JVM, hãy đợi Java 8, bạn thậm chí không cần chỉ định -Xmx, các cài đặt không gian meta sẽ giải quyết nhu cầu bộ nhớ JVM và nó sẽ tự động phát triển.

Có nhiều thứ để tạo một lớp hơn là phân bổ bộ nhớ. Ngoài ra còn có khởi tạo, tôi không chắc tại sao phần đó không được bao gồm trong tất cả các câu trả lời. Các lớp bình thường chứa một số biến và thực hiện một số hình thức khởi tạo và điều đó không miễn phí. Tùy thuộc vào lớp là gì, nó có thể đọc các tệp hoặc thực hiện bất kỳ số lượng hoạt động chậm nào khác.

Vì vậy, chỉ cần xem xét những gì các nhà xây dựng lớp làm, trước khi tìm hiểu xem nó có miễn phí hay không.

GC của Java thực sự được tối ưu hóa rất nhiều về việc tạo ra nhiều đối tượng nhanh chóng theo kiểu "nổ". Từ những gì tôi có thể hiểu, họ sử dụng bộ cấp phát tuần tự (bộ cấp phát O (1) nhanh nhất và đơn giản nhất cho các yêu cầu có kích thước thay đổi) cho loại "chu kỳ nổ" đó vào không gian bộ nhớ mà họ gọi là "không gian Eden" và chỉ khi các đối tượng tồn tại sau một chu kỳ GC, chúng có được di chuyển đến một nơi mà GC có thể thu thập chúng từng cái một không.

Như đã nói, nếu nhu cầu hiệu suất của bạn trở nên đủ quan trọng (như được đo bằng các yêu cầu cuối của người dùng thực sự), thì các đối tượng sẽ mang một chi phí nhưng tôi sẽ không nghĩ về nó nhiều về mặt sáng tạo / phân bổ. Nó liên quan nhiều hơn đến địa phương tham chiếu và kích thước bổ sung của tất cả các đối tượng trong Java theo yêu cầu để hỗ trợ các khái niệm như phản xạ và công văn động ( Floatlớn hơn float, thường là lớn hơn 4 lần trên 64 bit với các yêu cầu căn chỉnh của nó và mảng Floatkhông nhất thiết phải được đảm bảo để được lưu trữ liền kề từ những gì tôi hiểu).

Một trong những điều bắt mắt nhất tôi từng thấy được phát triển ở Java khiến tôi coi đó là một ứng cử viên nặng ký trong lĩnh vực của mình (VFX) là một công cụ theo dõi đường dẫn tiêu chuẩn đa luồng (không sử dụng bộ nhớ đệm chiếu xạ hoặc BDPT hoặc MLS hoặc bất cứ thứ gì khác) trên CPU cung cấp các bản xem trước thời gian thực hội tụ khá nhanh thành hình ảnh không nhiễu. Tôi đã làm việc với các chuyên gia trong C ++ cống hiến sự nghiệp của họ cho những việc như vậy với các trình biên dịch ưa thích trong tay, người gặp khó khăn trong việc đó.

Nhưng tôi đã quan sát xung quanh mã nguồn và trong khi nó sử dụng nhiều đối tượng với chi phí không đáng kể, các phần quan trọng nhất của trình theo dõi đường đi (BVH và tam giác và vật liệu) rất rõ ràng và cố tình tránh các đối tượng có lợi cho các mảng lớn của các kiểu nguyên thủy ( chủ yếu float[]và int[]), làm cho nó sử dụng ít bộ nhớ hơn và địa phương không gian được đảm bảo để đi từ floatmảng này sang mảng khác. Tôi không nghĩ rằng nó quá suy đoán để nghĩ rằng, nếu tác giả sử dụng các loại hình hộp thíchFloatở đó, nó sẽ có chi phí khá lớn so với hiệu suất của nó. Nhưng chúng ta đang nói về phần cực kỳ quan trọng nhất của động cơ đó, và tôi khá chắc chắn, vì nhà phát triển đã tối ưu hóa nó một cách khéo léo như thế nào, rằng anh ta đã đo lường điều đó và áp dụng tối ưu hóa đó một cách rất thận trọng, vì anh ta vui vẻ sử dụng các đối tượng ở mọi nơi khác chi phí tầm thường để theo dõi con đường thời gian thực ấn tượng của mình.

Tôi đã được một đồng nghiệp nói rằng trong việc tạo đối tượng Java là thao tác đắt nhất bạn có thể thực hiện. Vì vậy, tôi chỉ có thể kết luận để tạo ra càng ít đối tượng càng tốt.

Ngay cả trong một lĩnh vực quan trọng về hiệu suất như của tôi, bạn sẽ không viết các sản phẩm hiệu quả nếu bạn mắc kẹt ở những nơi không quan trọng. Tôi thậm chí sẽ đưa ra tuyên bố rằng các lĩnh vực quan trọng nhất về hiệu suất có thể đặt ra yêu cầu cao hơn về năng suất, vì chúng tôi cần tất cả thời gian để có thể điều chỉnh các điểm nóng thực sự quan trọng bằng cách không lãng phí thời gian vào những thứ không . Như với ví dụ về đường dẫn từ phía trên, tác giả đã khéo léo và thận trọng áp dụng những tối ưu hóa như vậy chỉ cho những nơi thực sự, thực sự quan trọng và có lẽ trong nhận thức sau khi đo, và vẫn vui vẻ sử dụng các đối tượng ở mọi nơi khác.

Như mọi người đã nói việc tạo đối tượng không phải là một chi phí lớn trong Java (nhưng tôi đặt cược lớn hơn hầu hết các hoạt động đơn giản như thêm, v.v.) và bạn không nên tránh nó quá nhiều.

Điều đó nói rằng nó vẫn còn là một chi phí, và đôi khi bạn có thể thấy mình đang cố gắng loại bỏ càng nhiều đối tượng càng tốt. Nhưng chỉ sau khi hồ sơ đã cho thấy rằng đây là một vấn đề.

Đây là một bài thuyết trình tuyệt vời về chủ đề: https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-ffic-java-tutorial.pdf

Tôi đã làm một microbenchmark nhanh chóng về điều này và tôi đã cung cấp đầy đủ các nguồn trong github. Kết luận của tôi là việc tạo đối tượng có tốn kém hay không không phải là vấn đề, nhưng việc liên tục tạo đối tượng với quan niệm rằng GC sẽ chăm sóc mọi thứ cho bạn sẽ khiến ứng dụng của bạn kích hoạt quy trình GC sớm hơn. GC là một quá trình rất tốn kém và tốt nhất là tránh nó bất cứ khi nào có thể và không cố gắng đẩy nó để đá vào.