Mengapa orang masih menggunakan tipe primitif di Jawa?


163

Sejak Java 5, kami sudah memiliki tinju / unboxing dari jenis primitif sehingga intdibungkus menjadi java.lang.Integer, dan seterusnya dan seterusnya.

Saya melihat banyak proyek Java baru akhir-akhir ini (yang pasti membutuhkan JRE setidaknya versi 5, jika tidak 6) yang menggunakan intdaripada java.lang.Integer, meskipun jauh lebih nyaman untuk menggunakan yang terakhir, karena memiliki beberapa metode pembantu untuk mengkonversi untuk longnilai et al.

Mengapa beberapa masih menggunakan tipe primitif di Jawa? Apakah ada manfaat nyata?


49
pernah berpikir tentang konsumsi memori dan kinerja?
Tedil

76
Saya menambahkan tag autoboxing ... dan menemukan bahwa tiga orang benar-benar mengikutinya. Betulkah? Orang-orang mengikuti tag AUTOBOXING?
corsiKa

4
@ glowcoder Mereka bukan orang yang sebenarnya, mereka hanya konsep abstrak yang menganggap bentuk manusia untuk menjawab pada SO. :)
biziclop

9
@TK Kocheran Sebagian besar karena new IntegeR(5) == new Integer(5)harus oleh aturan, evaluasi menjadi false.
biziclop

10
Lihat GNU Trove atau Mahout Collections atau HPPC atau ... untuk solusi koleksi tipe primitif. Kita yang peduli kecepatan menghabiskan waktu kita menggunakan tipe yang lebih primitif, tidak kurang.
bmargulies

Jawaban:


395

Dalam Java Efektif Joshua Bloch , Item 5: "Hindari membuat objek yang tidak perlu", ia memposting contoh kode berikut:

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);
}

dan butuh 43 detik untuk berjalan. Mengambil Long ke primitif membuatnya turun menjadi 6,8 detik ... Jika itu indikasi mengapa kita menggunakan primitif.

Kurangnya kesetaraan nilai asli juga merupakan masalah ( .equals()cukup bertele-tele dibandingkan dengan ==)

untuk biziclop:

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));
    }
}

Hasil dalam:

false
false
true
false

EDIT Mengapa (3) kembali truedan (4) kembali false?

Karena mereka adalah dua objek yang berbeda. 256 bilangan bulat yang paling dekat dengan nol [-128; 127] di-cache oleh JVM, jadi mereka mengembalikan objek yang sama untuk mereka. Di luar rentang itu, mereka tidak di-cache, jadi objek baru dibuat. Untuk membuat segalanya menjadi lebih rumit, JLS menuntut setidaknya 256 bobot terbang di-cache. Implementer JVM dapat menambahkan lebih banyak jika mereka inginkan, yang berarti ini dapat berjalan pada sistem di mana 1024 terdekat di-cache dan semuanya kembali benar ... #awkward


54
Sekarang bayangkan jika idinyatakan Longjuga!
ColinD

14
@ TREE - spec sebenarnya membutuhkan VM untuk membuat bobot terbang dalam rentang tertentu. Tapi sayangnya itu memungkinkan mereka untuk memperluas jangkauan itu, yang berarti bahwa program mungkin berperilaku berbeda pada VM yang berbeda. Begitu banyak untuk lintas platform ...
Daniel Earwicker

12
Java telah gagal, dengan semakin banyak pilihan desain yang buruk. Autoboxing adalah kegagalan total, tidak kuat, dapat diprediksi atau portabel. Aku benar-benar bertanya-tanya apa yang mereka pikirkan ... daripada memperbaiki dualitas objek primitif yang ditakuti, mereka berhasil membuatnya lebih buruk daripada di tempat pertama.
Pop Catalin

34
@Catalin Saya tidak setuju dengan Anda bahwa autoboxing adalah kegagalan total. Ini memiliki beberapa kelemahan, yang tidak berbeda dari desain lain yang bisa digunakan (termasuk tidak ada.) Mereka membuat sangat jelas apa yang Anda bisa dan tidak bisa harapkan, dan seperti desain lain yang mereka harapkan pengembang tahu dan mematuhi kontrak dari desain tersebut.
corsiKa

9
@NaftuliTzviKay Itu bukan "kegagalan." Mereka membuatnya SANGAT JELAS bahwa ==operator melakukan perbandingan identitas referensi pada Integerekspresi dan perbandingan kesetaraan nilai pada intekspresi. Integer.equals()ada karena alasan ini. Anda tidak boleh menggunakan ==untuk membandingkan nilai dalam tipe non-primitif apa pun. Ini adalah Java 101.
NullUserException

86

Autounboxing dapat menyebabkan sulit untuk menemukan NPE

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

Dalam kebanyakan situasi penugasan nol injauh lebih jelas daripada di atas.


43

Jenis kotak memiliki kinerja yang lebih buruk dan membutuhkan lebih banyak memori.


40

Tipe primitif:

int x = 1000;
int y = 1000;

Sekarang evaluasi:

x == y

Ini true. Sangat mengejutkan. Sekarang coba jenis kotak:

Integer x = 1000;
Integer y = 1000;

Sekarang evaluasi:

x == y

Ini false. Mungkin. Tergantung pada runtime. Apakah itu alasan yang cukup?


36

Selain masalah kinerja dan memori, saya ingin memunculkan masalah lain: ListAntarmuka akan rusak tanpa int.
Masalahnya adalah remove()metode kelebihan beban ( remove(int)vs.remove(Object) ). remove(Integer)akan selalu memutuskan untuk memanggil yang terakhir, jadi Anda tidak dapat menghapus elemen dengan indeks.

Di sisi lain, ada jebakan ketika mencoba untuk menambah dan menghapus int:

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

7
Itu akan rusak, ya. Namun, remove (int) adalah cacat desain IMO. Nama-nama metode tidak boleh kelebihan beban jika ada sedikit kemungkinan terjadi pencampuran.
MrBackend

4
@ MrBackend Cukup adil. Menariknya, Vectorsudah removeElementAt(int)sejak awal. remove(int)diperkenalkan dengan kerangka koleksi di Jawa 1.2.
xehpuk

6
@ McBackend: ketika ListAPI dirancang, Generics maupun Autoboxing tidak ada, jadi tidak ada peluang untuk mencampur remove(int)dan remove(Object)...
Holger

@ Franklin Yu: tentu, tetapi ketika merancang bahasa / versi baru tanpa kendala kompatibilitas, Anda tidak akan berhenti mengubah kelebihan yang tidak menguntungkan itu. Anda cukup menyingkirkan perbedaan primitif dan nilai kotak, sehingga pertanyaan yang digunakan tidak akan pernah muncul.
Holger

27

Bisakah Anda benar-benar membayangkan a

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

sebaliknya dengan java.lang.Integer? Java.lang.Integer tidak dapat diubah, sehingga setiap kenaikan putaran loop akan membuat objek java baru di heap, daripada hanya menambah int pada stack dengan instruksi JVM tunggal. Performanya akan sangat kejam.

Saya akan sangat tidak setuju bahwa ini adalah mode yang nyaman untuk menggunakan java.lang.Integer daripada int. Di sisi lain. Autoboxing berarti bahwa Anda dapat menggunakan int di mana Anda akan dipaksa untuk menggunakan Integer, dan kompiler java menangani memasukkan kode untuk membuat objek Integer baru untuk Anda. Autoboxing adalah tentang memungkinkan Anda untuk menggunakan int di mana Integer diharapkan, dengan kompiler memasukkan konstruksi objek yang relevan. Ini sama sekali tidak menghilangkan atau mengurangi kebutuhan int di tempat pertama. Dengan autoboxing Anda mendapatkan yang terbaik dari kedua dunia. Anda mendapatkan Integer yang dibuat untuk Anda secara otomatis ketika Anda membutuhkan objek java berbasis heap, dan Anda mendapatkan kecepatan dan efisiensi int ketika Anda hanya melakukan perhitungan aritmatika dan lokal.


19

Tipe primitif jauh lebih cepat:

int i;
i++;

Integer (semua Bilangan dan juga String a) adalah kekal ketik: sekali dibuat tidak dapat diubah. Jika iitu Integer, daripada i++akan membuat objek Integer baru - jauh lebih mahal dalam hal memori dan prosesor.


Anda tidak ingin satu variabel berubah jika Anda melakukan i++pada variabel lain, jadi Integer cukup tidak dapat diubah untuk dapat melakukan ini (atau setidaknya ini i++harus tetap membuat objek Integer baru). (Dan nilai-nilai primitif juga tidak dapat berubah - Anda hanya tidak berkomentar karena ini bukan objek.)
Paŭlo Ebermann

4
@ Paŭlo: Mengatakan bahwa nilai-nilai primitif tidak dapat diubah adalah sesuatu yang tidak berarti. Saat Anda menetapkan ulang variabel primitif ke nilai baru, Anda tidak membuat sesuatu yang baru. Tidak ada alokasi memori yang terlibat. Maksud Peter adalah: i ++ for a primitive tidak mengalokasikan memori, tetapi untuk sebuah objek memang demikian.
Eddie

@ Eddie: (Ini tidak perlu alokasi memori, bisa juga mengembalikan nilai yang di-cache. Untuk beberapa nilai kecil itu, saya pikir.) Maksud saya adalah bahwa kekekalan Integer di sini bukan titik penentu, Anda tetap ingin untuk memiliki objek lain, terlepas dari keabadian.
Paŭlo Ebermann

@ Paŭlo: Satu-satunya poin saya adalah Integer adalah urutan besarnya lebih lambat daripada primitif. Dan ini disebabkan oleh fakta bahwa tipe kotak tidak dapat diubah dan setiap kali Anda mengubah nilai, objek baru dibuat. Saya tidak mengklaim ada sesuatu yang salah dengan mereka atau fakta bahwa mereka tidak dapat berubah. Hanya saja mereka lebih lambat dan seorang programmer harus tahu itu. Lihatlah bagaimana harga Groovy tanpa tipe primitif jroller.com/rants/entry/why_is_groovy_so_slow
Peter Knego

1
Kekekalan dan ++merupakan herring merah di sini. Bayangkan Java ditingkatkan ke operator dukungan overloading dalam cara yang sangat sederhana, sehingga jika kelas (seperti Integermemiliki sebuah metode plus, maka Anda bisa menulis i + 1bukan i.plus(1). Dan menganggap juga bahwa compiler cukup pintar untuk memperluas i++ke i = i + 1. Sekarang Anda bisa mengatakan i++dan secara efektif "meningkatkan variabel i" tanpa Integerbisa berubah
Daniel Earwicker

16

Pertama dan terpenting, kebiasaan. Jika Anda telah mengkodekan di Jawa selama delapan tahun, Anda mengumpulkan banyak inersia. Mengapa berubah jika tidak ada alasan kuat untuk melakukannya? Ini bukan seolah-olah menggunakan kotak primitif datang dengan kelebihan tambahan.

Alasan lainnya adalah untuk menegaskan bahwa nullitu bukan opsi yang valid. Tidak ada gunanya dan menyesatkan untuk menyatakan jumlah dua angka atau variabel loop sebagai Integer.

Ada aspek kinerja juga, sementara perbedaan kinerja tidak kritis dalam banyak kasus (meskipun ketika itu, itu sangat buruk), tidak ada yang suka menulis kode yang dapat ditulis dengan mudah dengan cara yang lebih cepat kita sudah biasanya.


15
Saya tidak setuju. Aspek kinerja bisa sangat penting. Sangat sedikit dari ini mungkin inersia atau kekuatan kebiasaan.
Eddie

7
@ Eddie Itu bisa, tetapi sangat jarang. Percayalah, bagi kebanyakan orang, argumen kinerja hanyalah alasan.
biziclop

3
Saya juga ingin melindungi argumen kinerja. Di Android dengan Dalvik, setiap objek yang Anda buat akan meningkatkan "risiko" GC dipanggil dan semakin banyak objek yang Anda jeda akan lebih lama. Jadi membuat Integer alih-alih int dalam satu lingkaran mungkin akan dikenakan biaya beberapa frame yang dijatuhkan.
Igor Čordaš

1
@PSIXO Ini poin yang adil, saya menulisnya dengan mempertimbangkan sisi server murni Java. Perangkat seluler adalah hewan yang sangat berbeda. Tetapi poin saya adalah bahwa bahkan pengembang yang sebaliknya menulis kode yang buruk tanpa memperhatikan kinerja akan mengutip ini sebagai alasan, dari mereka ini terdengar sangat sebagai alasan.
biziclop

12

By the way, Smalltalk hanya memiliki objek (tidak primitif), namun mereka telah mengoptimalkan bilangan bulat kecil mereka (menggunakan tidak semua 32 bit, hanya 27 atau semacamnya) untuk tidak mengalokasikan ruang heap, tetapi cukup gunakan pola bit khusus. Juga objek umum lainnya (true, false, null) memiliki pola bit khusus di sini.

Jadi, setidaknya pada JVM 64-bit (dengan namespace pointer 64 bit) harus dimungkinkan untuk tidak memiliki objek Integer, Character, Byte, Short, Boolean, Float (dan Long kecil) sama sekali (terlepas dari ini dibuat secara eksplisit new ...()), hanya pola bit khusus, yang dapat dimanipulasi oleh operator normal dengan cukup efisien.


Saya seharusnya mengatakan "beberapa implementasi", karena ini tidak diatur oleh spesifikasi bahasa, saya pikir. (Dan sayangnya saya tidak bisa mengutip sumber apa pun di sini, itu hanya dari apa yang saya dengar di suatu tempat.)
Paŭlo Ebermann

ŭlo, JIT sudah menyimpan meta ke dalam pointer; termasuk, pointer dapat menyimpan info GC, atau Klass (mengoptimalkan Kelas adalah ide yang jauh lebih baik daripada mengoptimalkan Bilangan Bulat, yang saya tidak terlalu peduli). Mengubah pointer akan memerlukan, menggeser / cmp / kode jnz (atau sesuatu seperti itu) sebelum memuat setiap pointer. Cabang mungkin tidak akan diprediksi dengan sangat baik oleh perangkat keras (karena dapat berupa Tipe Nilai dan Objek normal) dan itu akan menyebabkan kinerja yang baik.
bestsss

3
Saya melakukan Smalltalk selama beberapa tahun. Optimalisasi masih cukup mahal, karena untuk setiap operasi pada int mereka harus membuka kedok dan menerapkannya kembali. Saat ini java setara dengan C ketika memanipulasi angka primitif. Dengan membuka topeng + topeng, maka kemungkinannya akan> 30% lebih lambat.
R.Moeller

9

Saya tidak percaya tidak ada yang menyebutkan apa yang saya pikir adalah alasan paling penting: "int" begitu, jadi lebih mudah untuk mengetik daripada "Integer". Saya pikir orang meremehkan pentingnya sintaksis singkat. Kinerja sebenarnya bukan alasan untuk menghindarinya karena sebagian besar waktu ketika seseorang menggunakan angka ada dalam indeks lingkaran, dan menambah dan membandingkan biaya-biaya itu tidak ada dalam loop non-sepele (apakah Anda menggunakan int atau Integer).

Alasan lain yang diberikan adalah bahwa Anda bisa mendapatkan NPE tapi itu sangat mudah untuk dihindari dengan tipe kotak (dan dijamin akan dihindari selama Anda selalu menginisialisasi mereka ke nilai-nilai non-nol).

Alasan lainnya adalah bahwa (Long baru (1000)) == (new Long (1000)) adalah salah, tetapi itu hanyalah cara lain untuk mengatakan bahwa ".equals" tidak memiliki dukungan sintaksis untuk jenis kotak (tidak seperti operator <,> , =, dll), jadi kita kembali ke alasan "sintaksis yang lebih sederhana".

Saya pikir contoh loop non-primitif Steve Yegge menggambarkan poin saya dengan sangat baik: http://sites.google.com/site/steveyegge2/language-trickery-and-ejb

Pikirkan ini: seberapa sering Anda menggunakan tipe fungsi dalam bahasa yang memiliki sintaksis yang baik untuk mereka (seperti bahasa fungsional, python, ruby, dan bahkan C) dibandingkan dengan java di mana Anda harus mensimulasikan mereka menggunakan antarmuka seperti Runnable dan Callable dan kelas tanpa nama.


8

Beberapa alasan untuk tidak menyingkirkan primitif:

  • Kompatibilitas mundur.

Jika dihilangkan, program lama apa pun tidak akan berjalan

  • JVM menulis ulang.

Seluruh JVM harus ditulis ulang untuk mendukung hal baru ini.

  • Jejak memori lebih besar.

Anda harus menyimpan nilai dan referensi, yang menggunakan lebih banyak memori. Jika Anda memiliki array byte yang sangat besar, menggunakan byte's secara signifikan lebih kecil daripada menggunakan Byte' s.

  • Masalah penunjuk kosong.

Mendeklarasikan int ikemudian melakukan hal-hal dengan tidak iakan menghasilkan masalah, tetapi menyatakan Integer idan kemudian melakukan hal yang sama akan menghasilkan NPE.

  • Masalah kesetaraan.

Pertimbangkan kode ini:

Integer i1 = 5;
Integer i2 = 5;

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

Akan salah. Operator harus kelebihan beban, dan itu akan menghasilkan penulisan ulang yang utama.

  • Lambat

Pembungkus objek secara signifikan lebih lambat daripada rekan-rekan primitif mereka.


i1 == i2; akan menjadi salah hanya jika i1> = 128. Jadi, contoh saat ini salah
Geniy

7

Objek jauh lebih berat daripada tipe primitif, jadi tipe primitif jauh lebih efisien daripada instance kelas pembungkus.

Tipe-tipe primitif sangat sederhana: misalnya int adalah 32 bit dan membutuhkan 32 bit dalam memori, dan dapat dimanipulasi secara langsung. Objek Integer adalah objek lengkap, yang (seperti objek apa pun) harus disimpan di heap, dan hanya dapat diakses melalui referensi (pointer) ke sana. Kemungkinan besar juga membutuhkan lebih dari 32 bit (4 byte) memori.

Yang mengatakan, fakta bahwa Jawa memiliki perbedaan antara tipe primitif dan non-primitif juga merupakan tanda usia bahasa pemrograman Java. Bahasa pemrograman yang lebih baru tidak memiliki perbedaan ini; kompiler dari bahasa seperti itu cukup pintar untuk mengetahui dengan sendirinya jika Anda menggunakan nilai-nilai sederhana atau objek yang lebih kompleks.

Misalnya, di Scala tidak ada tipe primitif; ada Int kelas untuk integer, dan Int adalah objek nyata (yang dapat Anda metode pada dll.). Ketika kompiler mengkompilasi kode Anda, ia menggunakan int primitif di belakang layar, jadi menggunakan Int sama efisiennya dengan menggunakan int primitif di Jawa.


1
Saya akan berasumsi bahwa JRE akan "pintar" cukup untuk melakukan ini dengan primitif dibungkus Java juga. Gagal.
Naftuli Kay

7

Selain apa yang dikatakan orang lain, variabel lokal primitif tidak dialokasikan dari heap, tetapi pada stack. Tetapi benda-benda dialokasikan dari tumpukan dan dengan demikian harus dikumpulkan dari sampah.


3
Maaf, ini salah. JVM yang cerdas dapat melakukan analisis pelarian pada setiap alokasi objek dan, jika mereka tidak dapat melarikan diri, mengalokasikannya pada stack.
rlibby

2
Ya, ini mulai menjadi fitur JVM modern. Dalam lima tahun, apa yang Anda katakan akan berlaku untuk sebagian besar JVM yang digunakan. Hari ini tidak. Saya hampir berkomentar tentang ini, tetapi memutuskan untuk tidak mengomentarinya. Mungkin aku seharusnya mengatakan sesuatu.
Eddie

6

Tipe primitif memiliki banyak keunggulan:

  • Kode sederhana untuk ditulis
  • Kinerja lebih baik karena Anda tidak membuat objek untuk variabel
  • Karena mereka tidak mewakili referensi ke objek, tidak perlu memeriksa nol
  • Gunakan tipe primitif kecuali Anda perlu memanfaatkan fitur tinju.

5

Sulit untuk mengetahui jenis optimasi apa yang terjadi di bawah selimut.

Untuk penggunaan lokal, ketika kompiler memiliki informasi yang cukup untuk membuat optimisasi tidak termasuk kemungkinan nilai nol, saya berharap kinerjanya sama atau serupa .

Namun, susunan primitif ternyata sangat berbeda dari koleksi primitif kotak. Ini masuk akal mengingat bahwa sangat sedikit optimasi yang mungkin dilakukan jauh di dalam koleksi.

Selain itu, Integermemiliki overhead logis yang jauh lebih tinggi dibandingkan dengan int: sekarang Anda harus khawatir tentang apakah int a = b + c;melempar pengecualian atau tidak .

Saya akan menggunakan primitif sebanyak mungkin dan mengandalkan metode pabrik dan autoboxing untuk memberi saya jenis kotak yang lebih kuat secara semantik ketika dibutuhkan.


5
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));

Milidetik diambil untuk mengulang kali '100000000' sekitar Panjang: 468

Milidetik yang diambil untuk mengulangi '100000000' kali sekitar lama: 31

Di samping catatan, saya tidak keberatan melihat sesuatu seperti ini menemukan jalannya ke Jawa.

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

Di mana for loop secara otomatis menambah loop1 dari 0 hingga 1000 atau

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

Di mana for loop secara otomatis mengurangi loop1 1000 ke 0.


2
  1. Anda memerlukan primitif untuk melakukan operasi matematika
  2. Primitif mengambil lebih sedikit memori seperti yang dijawab di atas dan berkinerja lebih baik

Anda harus bertanya mengapa jenis Kelas / Objek diperlukan

Alasan memiliki jenis Objek adalah untuk membuat hidup kita lebih mudah ketika kita berurusan dengan Koleksi. Primitif tidak dapat ditambahkan langsung ke Daftar / Peta daripada Anda harus menulis kelas pembungkus. Readymade Integer jenis Kelas membantu Anda di sini plus ia memiliki banyak metode utilitas seperti Integer.pareseInt (str)


2

Saya setuju dengan jawaban sebelumnya, menggunakan benda pembungkus primitif bisa mahal. Tetapi, jika kinerja tidak kritis dalam aplikasi Anda, Anda menghindari kelebihan saat menggunakan objek. Sebagai contoh:

long bigNumber = Integer.MAX_VALUE + 2;

Nilai bigNumber-2147483647, dan Anda mengharapkannya menjadi 2147483649. Ini adalah bug dalam kode yang akan diperbaiki dengan melakukan:

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

Dan bigNumberakan menjadi 2147483649. Bug semacam ini kadang-kadang mudah dilewatkan dan dapat menyebabkan perilaku atau kerentanan yang tidak diketahui (lihat CWE-190 ).

Jika Anda menggunakan objek pembungkus, kode yang sama tidak akan dikompilasi.

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

Jadi lebih mudah untuk menghentikan masalah semacam ini dengan menggunakan objek pembungkus primitif.

Pertanyaan Anda sudah dijawab, sehingga saya membalas hanya untuk menambahkan sedikit informasi lebih banyak yang tidak disebutkan sebelumnya.


1

Karena JAVA melakukan semua operasi matematika dalam tipe primitif. Pertimbangkan contoh ini:

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

Di sini, pengingat dan operasi unary plus tidak dapat diterapkan pada tipe Integer (Referensi), kompiler melakukan unboxing dan melakukan operasi.

Jadi, pastikan berapa banyak operasi autoboxing dan unboxing yang terjadi di program java. Karena, butuh waktu untuk melakukan operasi ini.

Secara umum, lebih baik menyimpan argumen tipe Referensi dan hasil tipe primitif.


1

The tipe primitif yang jauh lebih cepat dan memerlukan banyak memori kurang . Karena itu, kami mungkin ingin lebih suka menggunakannya.

Di sisi lain, spesifikasi bahasa Java saat ini tidak memungkinkan penggunaan tipe primitif dalam tipe parameter (generik), dalam koleksi Java atau API Refleksi.

Ketika aplikasi kita membutuhkan koleksi dengan sejumlah besar elemen, kita harus mempertimbangkan untuk menggunakan array dengan tipe yang lebih ekonomis.

* Untuk info rinci, lihat sumbernya: https://www.baeldung.com/java-primitive-vs-objects


0

Singkatnya: tipe primitif lebih cepat dan membutuhkan lebih sedikit memori daripada yang kotak

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.