Java’da nesne yaratmadan kaçınmalı mıyız?

Bir meslektaşım tarafından Java nesnesi yaratmada gerçekleştirebileceğiniz en pahalı işlem olduğu söylendi. Bu yüzden sadece mümkün olduğu kadar az nesne oluşturmaya karar verdim.

Bu, nesneye yönelik programlamanın amacını yenmek için biraz görünüyor. Nesneler yaratmıyorsak, optimizasyon için sadece bir tane uzun C sınıfı yazıyoruz.

Meslektaşınızın ne hakkında konuştukları hakkında hiçbir fikri yok.

En pahalı operasyonunuz onları dinliyor olacaktı . Sizi, on yıldan daha eski olan bilgilere (bu cevabın asıl tarihi itibariyle) yanı sıra burada göndermek ve İnternet'i gerçeği araştırmak için zaman harcamak zorunda bırakarak sizi yanlış yönlendirerek zamanınızı boşa harcadılar .

Umarım onlar sadece on yıl önce duydukları veya okudukları bir şeyi cahilce yetersiz tutarlar ve daha iyisini bilmiyorlar. Ben de şüpheli olarak söylediklerini başka bir şey alırdım, bu her iki şekilde de güncel olan herkes tarafından iyi bilinen bir yanlışlık olmalı.

Herşey bir Nesnedir (hariç primitives)

İlkellerden ( int, long, double, vb.) Başka her şey Java'daki Nesnelerdir. Java'da Nesne oluşturulmasını önlemenin bir yolu yoktur.

Java'da bellek ayırma stratejileri nedeniyle nesne oluşturma çoğu durumda C ++ 'dan daha hızlıdır ve JVM'deki diğer her şeye kıyasla tüm pratik amaçlar için "özgür" kabul edilebilir .

1990'ların sonlarında olduğu gibi, 2000'lerin başlarında JVM uygulamaları, Object'lerin fiili tahsisinde genel bir performans gösterdi. En azından 2005'ten beri durum böyle değildi.

Eğer melodi Eğer -Xmsdoğru çalıştırmak için uygulama için gereken tüm hafızayı desteklemek için, GC çalıştırmak ve kısa ömürlü programlar may asla GC hiç modern GC uygulamalarda çöp en süpürmek zorunda asla.

Yine de kırmızı bir ringa balığı olan boş alanı denemeyi ve en üst düzeye çıkarmaz, çalışma zamanının performansını en üst düzeye çıkarır. Bu JVM Yığınının neredeyse her zaman% 100 tahsis edildiği anlamına gelirse, öyle olsun. Ücretsiz JVM yığın hafızası size zaten orada oturan hiçbir şey vermiyor.

GC'nin sistemin geri kalan kısmına yararlı bir şekilde belleği boşaltacağı yanılgısı vardır, bu tamamen yanlıştır!

JVM yığını büyüyüp daralmaz, böylece sistemin geri kalanı JVM Yığındaki boş hafızadan olumlu bir şekilde etkilenir . -XmsBaşlangıçta belirtilenlerin ALL'sini tahsis eder ve sezgisel olanı, JVM'nin bu örneği tamamen sona erene kadar herhangi bir işletim sistemi işlemiyle paylaşılmak üzere bu belleğin hiçbir zaman işletim sistemine geri bırakılmamasıdır. -Xms=1GB -Xmx=1GBherhangi bir zamanda gerçekte ne kadar nesne oluşturulduğuna bakılmaksızın 1GB RAM tahsis eder. Yığın belleğinin yüzdelerinin serbest bırakılmasını sağlayan bazı ayarlar vardır, ancak tüm pratik amaçlar için JVM , bunun gerçekleşmesi için hiçbir zaman bu hafızanın yeteri kadarını serbest bırakamaz.bu yüzden başka hiçbir işlem bu belleği geri alamaz, bu nedenle sistemin geri kalanı JVM Yığınından da özgür olmamaktan faydalanamaz. Bunun için bir RFE 29-NOV-2006’da “kabul edildi” , ancak bu konuda hiçbir şey yapılmadı. Bu davranış otorite kimsenin endişesi olarak kabul edilmez.

Çok sayıda kısa, kısa ömürlü nesnenin yaratılmasının JVM'nin uzun süre duraklatmasına neden olduğu yanılgısı vardır, bu şimdi de yanlıştır.

Mevcut GC algoritmaları kısa ömürlü birçok küçük nesne oluşturmak için optimize edilmiştir , yani her programdaki Java nesneleri için temelde% 99 sezgiseldir. Yapılan girişimler Nesne havuzu oluşturma aslında JVM çoğu durumda kötü performans yapacaktır.

Bugün havuza ihtiyaç duyan tek Nesneler, JVM'ye harici sonlu kaynakları ifade eden Nesneler ; Soketler, Dosyalar, Veritabanı Bağlantıları vb. Yeniden kullanılabilir. Normal nesneler, bellek konumlarına doğrudan erişmenize izin veren dillerle aynı şekilde birleştirilemez . Nesne önbelleğe alma farklı bir kavramdır ve bazı insanların doğal olarak havuzlama dedikleri şey olabilir veya olmayabilir , iki kavram aynı değildir ve karıştırılmamalıdır.

Modern GC algoritmaları bu soruna sahip değil çünkü belirli bir nesilde boş hafıza gerektiğinde bir programa tahsis edilmiyorlar, tahsil ediyorlar. Yığın yeterince büyükse, duraklamalara neden olacak kadar uzun zamandır hiçbir ayrılma gerçekleşmez.

Nesneye Yönelik Dinamik diller, artık hesaplamaya duyarlı testlerde bile günümüzde C atıyor.

Alt satır: Nesneleri oluşturmak için kısayollar almak için tasarımınızdan ödün vermeyin. Gereksiz yere nesne oluşturmaktan kaçının. Mantıklıysa, gereksiz işlemlerden kaçınmak için tasarım yapın (her türden).

Çoğu cevabın aksine - evet, nesne tahsisinin DOES ile ilgili bir maliyeti vardır. Düşük bir maliyettir, ancak gereksiz nesneler oluşturmaktan kaçınmalısınız. Kodunuzda gereksiz hiçbir şeyden kaçınmanız gerektiği gibi. Büyük nesne grafikleri GC'yi yavaşlatır, muhtemelen daha fazla yöntem çağrısı yapacağınız, daha fazla CPU önbellek özeti tetikleyemediğiniz ve işleminizin düşük RAM durumlarında diske aktarılma olasılığını artıracağınız için daha uzun yürütme süreleri anlamına gelir.

Birisi bunun son derece önemli bir olay olduğunu söyleyemeden önce - Optimize etmeden önce ~ 50 satır veri işlemek için 20 + MB nesne yaratan uygulamaları profillendirdim. Dakikada yüze kadar istek gönderene kadar ve aniden dakikada 2GB veri oluşturduğunuzda, bu testte gayet iyi. 20 req / sn yapmak istiyorsanız, 400 MB nesneler yaratıyor ve sonra onu atıyorsunuz. 20 req / sn, iyi bir sunucu için küçük.

Aslında, Java dilinin (veya diğer yönetilen herhangi bir dilin) ​​mümkün kıldığı bellek yönetimi stratejileri nedeniyle, nesne oluşturma, genç kuşak adı verilen bir bellek bloğundaki bir göstergeyi arttırmaktan biraz daha fazlasıdır. Boş hafıza araması gereken C'den çok daha hızlı.

Maliyetin diğer kısmı nesne imhasıdır, ancak C ile karşılaştırmak zordur. Bir koleksiyonun maliyeti uzun vadede kaydedilen nesnelerin miktarına dayanmaktadır, ancak koleksiyonların sıklığı yaratılan nesnelerin miktarına dayanmaktadır ... Sonunda, hala C tarzı bellek yönetiminden çok daha hızlı.

Diğer posterler Java'da nesne oluşturmanın oldukça hızlı olduğunu ve normal Java uygulamalarında genellikle endişelenmemelisiniz.

Çok özel durumlarda bir çift vardır olduğunu nesne oluşturmayı önlemek için iyi bir fikir.

• Gecikme duyarlı bir uygulama yazarken ve GC duraklamalarını önlemek istediğinizde. Ne kadar çok nesne üretirseniz, GC o kadar çok olur ve duraklama şansı o kadar artar. Bu, oyunlar, bazı medya uygulamaları, robotik kontrol, yüksek frekanslı ticaret vb. İle ilgili geçerli bir değerlendirme olabilir. Çözüm, önünüzdeki tüm nesneleri / dizileri önceden tahsis etmek ve yeniden kullanmaktır. Javolution , bu tür yetenek sağlamada uzmanlaşmış kütüphaneler var . Fakat tartışmasız, gecikmeyi gerçekten önemsiyorsanız, Java veya C # :-) yerine C / C ++ / assembler kullanıyor olmalısınız.
• Kutulu ilkellerden (Çift, Tam sayı vb.) Kaçınmak , bazı durumlarda çok yararlı bir mikro optimizasyon olabilir. Kutusuz ilkel (çift, int vb.) Nesne başına düşen ek yükten kaçındığından, sayısal işleme vb. Gibi daha yoğun CPU yoğun işlerdir. Genellikle, ilkel diziler Java'da çok iyi performans gösterir, bu nedenle bunları sayı çatırmak için kullanmak istersiniz başka türlü nesneler.
• In kısıtlı bellek durumlarında her nesneler küçük yükü (JVM uygulamaya bağlı tipik 8-16 bayt) taşır beri nesnesi oluşturulur (aktif) sayısını en aza indirmek istiyoruz. Bu gibi durumlarda, verilerinizi çok sayıda küçük nesne yerine saklamak için az sayıda büyük nesneyi veya diziyi tercih etmelisiniz.

Meslektaşınızın söylediklerinde bir çekirdek çekirdeği var. Saygılarımla, nesne yaratma ile ilgili sorunun aslında çöp toplama olduğunu düşünüyorum . C ++ 'da programlayıcı hafızanın nasıl tahsis edileceğini tam olarak kontrol edebilir. Program, istediği kadar kısa veya çok miktarda toplanabilir. Ayrıca, C ++ programı onu oluşturandan farklı bir iş parçacığı kullanarak kabuğunu atabilir. Bu nedenle şu anda çalışan ipliğin temizlenmesi için hiçbir zaman durması gerekmez.

Buna karşılık, Java Virtual Machine (JVM) kullanılmayan hafızayı geri almak için kodunuzu düzenli aralıklarla durdurur. Çoğu Java geliştiricisi bu duraklamayı asla farketmez, çünkü genellikle seyrek ve çok kısadır. Topladığınız su miktarı veya JVM'niz ne kadar kısıtlıysa, bu duraklamalar o kadar sık ​​olur. Bu işlemi görselleştirmek için VisualVM gibi araçlar kullanabilirsiniz .

Java'nın son sürümlerinde, çöp toplama (GC) algoritması ayarlanabilir . Genel bir kural olarak, duraklamaları ne kadar kısaltmak isterseniz, sanal makinedeki ek yük o kadar pahalı olur (yani, GC işlemini koordine etmek için kullanılan CPU ve bellek).

Bu ne zaman önemli olabilir? Tutarlı bir milisaniyelik cevap oranını ne zaman önemsiyorsanız, GC ile ilgileneceksiniz. Java'da yazılmış otomatik işlem sistemleri duraklamaları en aza indirmek için JVM'yi yoğun şekilde ayarlar. Aksi takdirde Java yazacak olan firmalar, sistemlerin her zaman çok duyarlı olmaları gereken durumlarda C ++ 'a dönüşür.

Kayıt için, ben do not genelde nesne kaçınma affetmek! Nesne yönelimli programlama için varsayılan değerdir. Bu yaklaşımı yalnızca GC yolunuza çıkarsa ve ardından JVM'yi daha az süre duraklatmak üzere ayarlamaya çalıştıktan sonra ayarlayın. Java performans ayarlaması hakkında iyi bir kitap, Charlie Hunt ve Binu John'un Java Performansı .

Genel gider nedeniyle Java'da çok fazla nesne oluşturmaktan vazgeçebileceğiniz bir durum var - Android platformunda performans için tasarlandı

Bunun dışında, yukarıdaki cevaplar doğrudur.

GC birçok kısa ömürlü nesne için ayarlanmıştır

Eğer nesne tahsisini önemsiz bir şekilde azaltabilirseniz,

Bir örnek, bir döngü içinde bir dize inşa ediyor olacak, naif bir şekilde

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

bu Stringher +=işlemde yeni bir nesne yaratır (artı a StringBuilderve yeni temel karakter dizisi)

Bunu kolayca yeniden yazabilirsiniz:

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

Bu desen (değişmez sonuç ve yerel değişken bir ara değer) başka şeylere de uygulanabilir.

ama bunun dışında hayaletleri kovalamak yerine gerçek tıkanıklığı bulmak için bir profilci bulmalısın

Joshua Bloch (Java platformu oluşturucularından biri) 2001 yılında Effective Java adlı kitabında yazdı :

Kendi nesne havuzunuzu koruyarak nesne oluşturmayı önlemek, havuzdaki nesneler çok ağır olmadıkça kötü bir fikirdir. Bir nesne havuzunu haklı çıkartan bir nesnenin prototipik örneği bir veritabanı bağlantısıdır. Bağlantının kurulmasının maliyeti, bu nesnelerin yeniden kullanılmasının anlamlı olacağı kadar yüksektir. Bununla birlikte, genel olarak konuşursak, kendi nesne havuzlarınızı sürdürmek kodunuzu zorlar, bellek ayak izini artırır ve performansı bozar. Modern JVM uygulamaları, hafif nesneler üzerinde bu tür nesne havuzlarından daha iyi performans gösteren yüksek oranda optimize edilmiş çöp toplayıcılara sahiptir.

Bu gerçekten belirli bir uygulamaya bağlı, bu yüzden genel olarak söylemek gerçekten zor. Ancak, bir uygulamada nesne oluşturma işlemi aslında bir performans darboğazı olsaydı çok şaşırırdım. Yavaş olsalar bile, kod stili yararı muhtemelen performanstan ağır basacaktır (aslında kullanıcıya farkedilmezse)

Her durumda, tahmin yerine gerçek performans darboğazlarını belirlemek için kodunuzu belirleyene kadar bu konular hakkında endişelenmeye başlamamalısınız. O zamana kadar kod okunabilirliği için en iyi olanı performanstan ziyade yapmalısınız.

Bence meslektaşın gereksiz nesne yaratma perspektifinden söylemiş olmalı. Aynı nesneyi sık sık oluşturuyorsanız, o nesneyi paylaşmak daha iyidir. Nesne oluşturma işleminin karmaşık olduğu ve daha fazla bellek harcadığı durumlarda bile, o nesneyi klonlamak ve bu karmaşık nesne oluşturma işlemini oluşturmaktan kaçınmak isteyebilirsiniz (Bu, gereksiniminize bağlıdır). "Nesne oluşturma pahalı" ifadesi bağlamında alınması gerektiğini düşünüyorum.

JVM bellek gereksinimleri söz konusu olduğunda, Java 8'i bekleyin, -Xmx belirtmeniz bile gerekmiyor, meta alan ayarları JVM bellek ihtiyacını karşılayacak ve otomatik olarak büyüyecek.

Bellek ayırmaktan çok bir sınıf yaratmaktan daha fazlası var. Aynı zamanda ilklendirme de var, neden bu kısmın tüm cevaplar kapsamında olmadığından emin değilim. Normal sınıflar bazı değişkenler içerir ve bir tür başlatma şekli yapar ve bu ücretsiz değildir. Sınıfın ne olduğuna bağlı olarak, dosyaları okuyabilir veya başka yavaş işlemler yapabilir.

Bu yüzden, sınıf kurucusunun ne yaptığını göz önünde bulundurun, özgür olup olmadığını öğrenmeden önce.

Java’nın GC’si, hızlı bir şekilde “patlama” şeklinde hızlı bir şekilde çok sayıda nesne oluşturma açısından gerçekten optimize edilmiştir. Anlayabildiğim kadarıyla, bu tür bir "patlama döngüsü" için "Eden alanı" olarak adlandırdıkları bir bellek alanına sıralı bir ayırıcı (değişken boyutta talepler için en hızlı ve en basit O (1) ayırıcısı) kullanıyorlar ve sadece nesneler devam ederse Bir GC döngüsünden sonra, GC'nin onları birer birer toplayabileceği bir yere taşınırlar.

Bununla birlikte, performansınızın yeterince kritik hale gelmesi durumunda (gerçek kullanıcı sonu gereklilikleriyle ölçülen şekilde), nesneler bir yükü taşır, ancak oluşturma / tahsis etme konusunda fazla düşünmezdim. Bu yansıma ve dinamik sevk (gibi kavramları desteklemek için gerektiği gibi başvurusu konum ve Java tüm nesnelerin ek boyutu ile yapmak daha vardır Floatdaha büyük floatolan hizalama gereksinimleri ile 64 bit üzerine daha büyük 4 kat gibi bir şey genellikle, ve bir dizi Floatmutlaka anladığımdan bitişik olarak saklanacağı garanti edilmez).

Java'da geliştirdiğim en dikkat çekici şeylerden biri, kendi alanımdaki (VFX) ağır bir rakip olduğunu düşünmemi sağlayan interaktif, çok iş parçacıklı bir standart yol izleyiciydi (ışınım önbelleği veya BDPT veya MLS veya başka bir şey kullanmıyor). Gürültüsüz bir görüntüye oldukça hızlı bir şekilde yaklaşan gerçek zamanlı önizlemeler sağlayan CPU. C ++ 'daki profesyonellerle çalıştım, kariyerlerini ellerinde böyle yapmakta zorlanan süslü profilcilerle olan şeylere adadım.

Ancak kaynak koduna baktım ve önemsiz maliyetle çok sayıda nesne kullanırken, yol izleyicinin en kritik kısımları (BVH ve üçgenler ve materyaller), ilkel türlerin büyük dizileri lehine çok net ve kasten kaçındı. çoğunlukla float[]ve int[]), floatdiziden birinden diğerine geçmek için çok daha az bellek ve garantili mekansal konum kullandı . Yazarın beğendiği kutulu türleri kullanması durumunda bunu düşünmenin spekülatif olduğunu sanmıyorum.Floatorada, performansı için oldukça büyük bir maliyetle gelirdi. Ama biz bu motorun en kritik kısmından bahsediyoruz ve geliştiricinin ne kadar ustaca optimize ettiği göz önüne alındığında, bu optimizasyonu ne kadar ustaca kullandığı ve bu optimizasyonu çok ama çok ustaca kullandığı için eminim. etkileyici gerçek zamanlı yol izleyicisine önemsiz maliyet.

Bir meslektaşım tarafından Java nesnesi yaratmada gerçekleştirebileceğiniz en pahalı işlem olduğu söylendi. Bu yüzden sadece mümkün olduğu kadar az nesne oluşturmaya karar verdim.

Benimki kadar kritik performans gerektiren bir alanda bile, eğer önemli olmayan yerlere girerseniz, verimli ürünler yazmazsınız. Performans açısından en kritik alanların üretkenliğe daha da talep edebileceği iddiasını bile öne süreceğim, çünkü fazladan zaman harcamamamız gereken zaman harcayacağımız zamana ihtiyacımız var. . Yukarıdaki yukarıdaki yol izleyici örneğinde olduğu gibi, yazar ustaca ve ustaca bu tür optimizasyonları yalnızca gerçekten, gerçekten önemli olan ve muhtemelen ölçümden sonra en önemlisi ve her yerde mutlu bir şekilde kullanılan nesnelere uyguladı.

İnsanların nesnenin yaratılmasının Java'da büyük bir maliyet olmadığını söylediği gibi (ancak ekleme, vb. Gibi basit işlemlerden daha büyük bahse girerim) ve bundan çok fazla kaçınmamalısınız.

Bu hala bir maliyet olduğunu söyledi ve bazen kendinizi olabildiğince fazla nesneyi kazımaya çalışırken bulabilirsiniz. Ancak sadece profillemeden sonra bunun bir sorun olduğunu göstermiştir.

İşte konuyla ilgili harika bir sunum: https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf

Bununla ilgili hızlı bir mikrobölge yaptım ve github'da tam kaynaklar sağladım. Benim sonucum, nesnelerin yaratılmasının pahalı olup olmadığının sorun olmadığı, ancak GC'nin sizin için dikkat edeceği düşüncesiyle sürekli olarak nesneler yaratmanın uygulamanızın GC sürecini daha erken tetiklemesini sağlayacağıdır. GC çok pahalı bir işlemdir ve mümkün olduğunda önlemek ve en iyisi tekmelemek için zorlamamaktır.