İnsanlar neden Java'da hala ilkel türler kullanıyor?

Java 5'ten beri, ilkel türlerin boksu / kutudan çıkarılması vardı, böylece intsarılmış java.lang.Integervb.

Son zamanlarda kullanmak için bir sürü yeni Java projesi görüyorum ( kesinlikle en az sürüm 5'in bir JRE'sini gerektirir), intyerine java.lang.Integerkullanmak için çok daha uygun olsa da, dönüştürmek için birkaç yardımcı yöntem olduğu için için longdeğerler ve diğ.

Neden bazıları hala Java'da ilkel türleri kullanıyor? Maddi bir fayda var mı?

Joshua Bloch'un Etkili Java'sında , Madde 5: "Gereksiz nesneler oluşturmaktan kaçının", aşağıdaki kod örneğini yayınlar:

public static void main(String[] args) {
    Long sum = 0L; // uses Long, not long
    for (long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;
    }
    System.out.println(sum);
}

ve koşması 43 saniye sürer. Long'u ilkele sokmak onu 6.8 saniyeye indirir ... Bu ilkel neden kullandığımızın bir göstergesi ise.

Yerel değer eşitliğinin olmaması da bir endişe kaynağıdır ( .equals()ile karşılaştırıldığında oldukça ayrıntılıdır ==)

biziclop için:

class Biziclop {

    public static void main(String[] args) {
        System.out.println(new Integer(5) == new Integer(5));
        System.out.println(new Integer(500) == new Integer(500));

        System.out.println(Integer.valueOf(5) == Integer.valueOf(5));
        System.out.println(Integer.valueOf(500) == Integer.valueOf(500));
    }
}

Sonuçlar:

false
false
true
false

_^EDIT (3) neden geri dönüyor trueve (4) geri dönüyor false?

Çünkü onlar iki farklı nesne. Sıfıra en yakın 256 tam sayı [-128; 127] JVM tarafından önbelleğe alınır, böylece bunlar için aynı nesneyi döndürürler. Bu aralığın ötesinde, önbelleğe alınmazlar, böylece yeni bir nesne oluşturulur. İşleri daha karmaşık hale getirmek için JLS, en az 256 sinek ağırlığının önbelleğe alınmasını talep ediyor . JVM uygulayıcıları istedikleri zaman daha fazlasını ekleyebilirler, yani bu en yakın 1024'ün önbelleğe alındığı ve hepsinin doğru döndüğü bir sistemde çalışabilir ... #awkward

Otomatik kutudan ayrılması zor NPE'lere yol açabilir

Integer in = null;
...
...
int i = in; // NPE at runtime

Çoğu durumda null atama, inyukarıdakinden çok daha az belirgindir.

Kutulu tipler daha düşük performansa sahiptir ve daha fazla bellek gerektirir.

İlkel tipler:

int x = 1000;
int y = 1000;

Şimdi değerlendirin:

x == y

Öyle true. Çok şaşırtıcı değil. Şimdi kutulu türleri deneyin:

Integer x = 1000;
Integer y = 1000;

Şimdi değerlendirin:

x == y

Öyle false. Muhtemelen. Çalışma zamanına bağlıdır. Bu sebep yeterli mi?

Performans ve bellek sorunlarının yanı sıra başka bir sorun daha ortaya çıkarmak istiyorum: ListArayüz olmadan bozulacaktı int.
Sorun aşırı yüklenmiş remove()yöntemdir ( remove(int)vs. remove(Object)). remove(Integer)her zaman ikincisini çağırmaya karar verir, böylece bir öğeyi dizine göre kaldıramazsınız.

Öte yandan, bir eklemeye ve kaldırmaya çalışırken bir tuzak var int:

final int i = 42;
final List<Integer> list = new ArrayList<Integer>();
list.add(i); // add(Object)
list.remove(i); // remove(int) - Ouch!

Gerçekten hayal edebiliyor musun

  for (int i=0; i<10000; i++) {
      do something
  }

bunun yerine java.lang.Integer ile döngü? Bir java.lang.Integer değişmezdir, bu nedenle döngü etrafındaki her artış, tek bir JVM komutuyla yığıntaki int değerini artırmak yerine yığın üzerinde yeni bir java nesnesi oluşturur. Performans şeytani olur.

Gerçekten java.lang.Integer kullanmak int çok daha uygun olduğunu kabul etmiyorum. Aksine. Otomatik kutulama, int'i aksi halde Tamsayı kullanmaya zorlayabileceğiniz bir yerde kullanabileceğiniz anlamına gelir ve java derleyicisi sizin için yeni Integer nesnesini oluşturmak için kod eklemeyle ilgilenir. Otomatik kutulama, derleyicinin ilgili nesne yapısını ekleyerek bir Tamsayı beklenen yerlerde bir int kullanmanıza izin vermekle ilgilidir. Başlangıçta int ihtiyacını hiçbir şekilde ortadan kaldırmaz veya azaltmaz. Otomatik boks ile her iki dünyanın da en iyisini elde edersiniz. Bir yığın tabanlı java nesnesine ihtiyacınız olduğunda sizin için otomatik olarak oluşturulan bir Tamsayı alırsınız ve yalnızca aritmetik ve yerel hesaplamalar yaparken int'in hızını ve verimliliğini elde edersiniz.

İlkel türler çok daha hızlıdır:

int i;
i++;

Tamsayı (tüm Sayılar ve ayrıca bir Dize) değişmez bir türdür: oluşturulduktan sonra değiştirilemez. Eğer idaha Tamsayı oldu i++çok daha pahalı bellek ve işlemci bakımından - Yeni bir Integer nesnesi yaratacak.

Her şeyden önce alışkanlık. Java'da sekiz yıl kod yazdıysanız, kayda değer miktarda atalet biriktirirsiniz. Zorlayıcı bir neden yoksa neden değişsin? Kutulu ilkelleri kullanmanın herhangi bir ekstra avantajı varmış gibi değil.

Diğer neden nullgeçerli bir seçenek olmadığını iddia etmektir. İki sayının veya bir döngü değişkeninin toplamını olarak bildirmek anlamsız ve yanıltıcı olacaktır Integer.

Performans yönü de var, ancak performans farkı birçok durumda kritik olmasa da (oldukça kötü olsa da), kimse zaten daha hızlı bir şekilde daha kolay yazılabilecek bir kod yazmayı sevmiyor alışığım.

Bu arada, Smalltalk'ın yalnızca nesneleri (ilkelleri yok) vardır ve yine de küçük tam sayılarını (32 bitin tümünü değil, sadece 27 veya benzeri) kullanarak herhangi bir yığın alanı ayırmayacak, ancak özel bir bit deseni kullanacak şekilde optimize ettiler. Ayrıca diğer ortak nesnelerin (doğru, yanlış, boş) burada özel bit kalıpları vardı.

Bu nedenle, en azından 64 bit JVM'lerde (64 bit işaretçi ad alanı ile), herhangi bir Tamsayı, Karakter, Bayt, Kısa, Boole, Kayan Nokta (ve küçük Uzun) nesnelerinin (bunların oluşturulmuş olanlar dışında) olması mümkün olmamalıdır açık bir şekilde new ...()), sadece normal operatörler tarafından oldukça verimli bir şekilde manipüle edilebilen özel bit kalıpları.

Kimsenin en önemli sebep olduğunu düşündüğümden bahsetmediğine inanamıyorum: "int" yazmak, "Tamsayı" dan çok daha kolay. Bence insanlar kısa bir sözdiziminin önemini hafife alıyorlar. Performans gerçekten onlardan kaçınmak için bir neden değildir, çünkü çoğu zaman sayıları kullandığınızda döngü dizinlerinde bulunur ve bu maliyetlerin artırılması ve karşılaştırılması önemsiz olmayan herhangi bir döngüde (int veya Integer kullanıyor olsanız da) hiçbir maliyeti yoktur.

Diğer bir neden ise NPE'leri alabilmenizdi, ancak kutulu türlerle kaçınılması son derece kolaydır (ve her zaman null olmayan değerlere başlattığınız sürece kaçınılması garanti edilir).

Diğer neden ise (new Long (1000)) == (new Long (1000)) 'in yanlış olması, ancak bu ".equals" ın kutulu türler için sözdizimsel desteği olmadığını söylemenin başka bir yolu (operatörlerin <,> , =, vb.), "basit sözdizimi" nedenine geri dönüyoruz.

Bence Steve Yegge'in ilkel olmayan döngü örneği benim açımı çok iyi gösteriyor: http://sites.google.com/site/steveyegge2/language-trickery-and-ejb

Şunu düşünün: Runnable ve Callable ve isimsiz sınıflar.

İlkellerden kurtulmamak için birkaç neden:

• Geriye dönük uyumluluk.

Elimine edilirse, eski programlar bile çalışmaz.

• JVM yeniden yazma.

JVM'nin tamamı bu yeni şeyi desteklemek için yeniden yazılmalıdır.

• Daha büyük bellek alanı.

Daha fazla bellek kullanan değeri ve referansı saklamanız gerekir. Çok sayıda baytınız varsa, byte's' kullanmak 's' den önemli ölçüde daha küçüktür Byte.

• Boş gösterici sorunları.

int iSonra bir şeyler yapmak bildirmek sorun yaratmaz i, ancak Integer ibunu bildirmek ve sonra yapmak bir NPE ile sonuçlanır.

• Eşitlik sorunları.

Bu kodu düşünün:

Integer i1 = 5;
Integer i2 = 5;

i1 == i2; // Currently would be false.

Yanlış olur. Operatörlerin aşırı yüklenmesi gerekecek ve bu da büyük bir yeniden yazma ile sonuçlanacaktır.

• Yavaş

Nesne sarmalayıcıları ilkel muadillerinden önemli ölçüde yavaştır.

Nesneler ilkel tiplerden çok daha ağırdır, bu nedenle ilkel tipler sarıcı sınıf örneklerinden çok daha verimlidir.

İlkel tipler çok basittir: örneğin bir int 32 bittir ve bellekte tam olarak 32 bit alır ve doğrudan manipüle edilebilir. Bir Tamsayı nesnesi, (herhangi bir nesne gibi) öbek üzerinde depolanması gereken ve ona yalnızca bir referans (işaretçi) aracılığıyla erişilebilen tam bir nesnedir. Büyük olasılıkla 32 bit'ten (4 bayt) fazla bellek alır.

Bununla birlikte, Java'nın ilkel ve ilkel olmayan türler arasında bir ayrımı olması, Java programlama dilinin yaşının bir işaretidir. Daha yeni programlama dillerinde bu ayrım yoktur; basit bir değer veya daha karmaşık nesneler kullanıyorsanız, böyle bir dilin derleyicisi kendi başına anlamaya yetecek kadar akıllıdır.

Örneğin, Scala'da ilkel tipler yoktur; tamsayılar için bir Int sınıfı vardır ve bir Int gerçek bir nesnedir (üzerinde yöntemler vs. yapabilirsiniz). Derleyici kodunuzu derlediğinde, sahnelerin arkasında ilkel ints kullanır, bu nedenle Int kullanmak Java'da ilkel int kullanmak kadar etkilidir.

Diğerlerinin söylediklerine ek olarak, ilkel yerel değişkenler öbekten değil, yığına ayrılır. Ancak nesneler öbekten ayrılır ve bu nedenle çöp toplanması gerekir.

İlkel türlerin birçok avantajı vardır:

• Yazmak için daha basit kod
• Değişken için bir nesne somutlaştırmadığınız için performans daha iyidir
• Bir nesneye yapılan bir referansı temsil etmedikleri için null değerlerini kontrol etmeye gerek yoktur
• Boks özelliklerinden yararlanmanız gerekmediği sürece ilkel türleri kullanın.

Kapakların altında ne tür optimizasyonların yapıldığını bilmek zor.

Yerel kullanım için, derleyici boş değer olasılığı dışında optimizasyon yapmak için yeterli bilgiye sahip olduğunda , performansın aynı veya benzer olmasını beklerim .

Bununla birlikte, ilkel dizileri , kutulu ilkel koleksiyonlarından çok farklıdır . Bu, bir koleksiyon içinde çok az optimizasyonun mümkün olduğu göz önüne alındığında mantıklıdır.

Ayrıca, ile karşılaştırıldığında Integerçok daha yüksek bir mantıksal yüke sahiptir int: şimdi int a = b + c;bir istisna atıp atmama konusunda endişelenmeniz gerekiyor .

İlkelleri olabildiğince çok kullanırdım ve bana ihtiyaç duyduklarında daha semantik olarak güçlü kutulu türleri vermek için fabrika yöntemlerine ve otomatik kutuya güvenirdim.

int loops = 100000000;

long start = System.currentTimeMillis();
for (Long l = new Long(0); l<loops;l++) {
    //System.out.println("Long: "+l);
}
System.out.println("Milliseconds taken to loop '"+loops+"' times around Long: "+ (System.currentTimeMillis()- start));

start = System.currentTimeMillis();
for (long l = 0; l<loops;l++) {
    //System.out.println("long: "+l);
}
System.out.println("Milliseconds taken to loop '"+loops+"' times around long: "+ (System.currentTimeMillis()- start));

Uzun: 468 civarında '100000000' kez döngü için alınan milisaniye

Milisaniye '100000000' kez uzun döngü için alınır: 31

Yan not etmek gerekirse, böyle bir şeyin Java'ya dönüştüğünü görmenin sakıncası olmaz.

Integer loop1 = new Integer(0);
for (loop1.lessThan(1000)) {
   ...
}

For döngüsü otomatik olarak loop1 değerini 0'dan 1000'e yükseltirse veya

Integer loop1 = new Integer(1000);
for (loop1.greaterThan(0)) {
   ...
}

For döngüsü otomatik olarak loop1 1000'i 0'a düşürür.

1. Matematiksel işlemler yapmak için ilkellere ihtiyacınız var
2. Temel öğeler yukarıda yanıtlandığı gibi daha az bellek ve daha iyi performans gösterir

Sınıf / Nesne türünün neden gerekli olduğunu sormalısınız

Nesne türüne sahip olmanın nedeni Koleksiyonlarla uğraşırken hayatımızı kolaylaştırmaktır. Temel öğeler doğrudan Liste / Haritaya eklenemez, bunun yerine bir sarmalayıcı sınıfı yazmanız gerekir. Hazır Integer türü Sınıflar burada size yardımcı olur ve Integer.pareseInt (str) gibi birçok yardımcı yöntem vardır

Önceki cevaplara katılıyorum, ilkel sarmalayıcı nesneleri kullanmak pahalı olabilir. Ancak, uygulamanızda performans kritik değilse, nesneleri kullanırken taşmaları önlersiniz. Örneğin:

long bigNumber = Integer.MAX_VALUE + 2;

Değeri bigNumber-2147483647'dir ve 2147483649 olmasını beklersiniz. Bu kodda yaparak düzeltilecek bir hata:

long bigNumber = Integer.MAX_VALUE + 2l; // note that '2' is a long now (it is '2L').

Ve bigNumberbazen cevapsız kolaydır ve bilinmeyen davranış veya güvenlik yol açabilir böcek Bu tür 2147483649. olurdu (bkz CWE-190 ).

Sarıcı nesneleri kullanırsanız, eşdeğer kod derlenmez.

Long bigNumber = Integer.MAX_VALUE + 2; // Not compiling

Bu nedenle, ilkel sarmalayıcı nesneleri kullanarak bu tür sorunları durdurmak daha kolaydır.

Sorunuz çoktan cevaplandı, daha önce bahsetmediğim biraz daha fazla bilgi eklemek için cevap veriyorum.

Çünkü JAVA tüm matematiksel işlemleri ilkel tiplerde yapar. Bu örneği düşünün:

public static int sumEven(List<Integer> li) {
    int sum = 0;
    for (Integer i: li)
        if (i % 2 == 0)
            sum += i;
        return sum;
}

Burada, hatırlatıcı ve tekli artı işlemleri Tamsayı (Referans) türüne uygulanamaz, derleyici kutudan çıkarmayı gerçekleştirir ve işlemleri yapar.

Bu nedenle, java programında kaç tane otomatik boks ve kutudan çıkarma işlemi gerçekleştirildiğinden emin olun. Bu nedenle, bu işlemleri gerçekleştirmek zaman alır.

Genel olarak, Referans ve ilkel türün sonucunu içeren argümanları tutmak daha iyidir.

İlkel türleri şunlardır çok daha hızlı ve çok gerektiren daha az bellek . Bu nedenle, bunları kullanmayı tercih edebiliriz.

Öte yandan, mevcut Java dili belirtimi, parametreli türlerde (jenerikler), Java koleksiyonlarında veya Yansıma API'sında ilkel türlerin kullanılmasına izin vermez.

Uygulamamız çok sayıda öğeye sahip koleksiyonlara ihtiyaç duyduğunda, mümkün olduğunca daha “ekonomik” tip dizileri kullanmayı düşünmeliyiz.

* Ayrıntılı bilgi için kaynağa bakın: https://www.baeldung.com/java-primitives-vs-objects

Özetlemek gerekirse: ilkel türler daha hızlıdır ve kutulu olanlardan daha az bellek gerektirir