richiama il nuovo costruttore Integer (int) inefficiente; utilizzare Integer.valueOf (int) invece

Question

Il mio obiettivo è ottimizzare il mio codice applicazione. Il mio codice è simile al seguente:

int a = 10; 
Map<String , Integer> myMap = new TreeMap<>(); 

myMap.put("first" , new Integer(a)); //[FindBugs] Method com.abc.xyz.Test.main(String[]) invokes inefficient new Integer(int) constructor; use Integer.valueOf(int) instead 

Quando ho fatto l'analisi statica da Findbugs in NetBeans, si vede che c'è un avviso/bug come "metodo richiama inefficiente nuovo (int) costruttore Integer; utilizzare Integer.valueOf (int) invece ".

so la differenza tra new Integer (int) vs Integer.valueOf (int).

Uno crea un oggetto aggiuntivo e l'altro no. Anche uno non memorizza nella cache e le altre cache.

Così ho modificato il mio codice come questo ...

m.put("first" , Integer.valueOf(a)); // Unnecessary boxing to Integer 

ma ancora una volta che dà anche avvertimento "boxe Inutile Integer" (dal redattore non per findbugs).

Così, ho cambiato di nuovo come in questo modo ....

m.put("first" , a); //No warning at all... 

che dà finalmente nessun avvertimento a tutti.

La mia domanda:

1.) Questa link suggeriscono che internamente (dal compilatore) m.put ("prima", a); sta convertendo in m.put ("first", Integer.valueOf (a));

(In questo esempio, c'è una List-ArrayList e qui Map-TreeMap ... FYI). allora perché l'editor dà avvertimento? E cosa dovrei fare? qual è il modo ottimizzato?

2.) Se invece di Mappa, se non v'è alcuna struttura di dati come HashTable allora ???

3.) Perché l'editor dà Box non necessario all'intero.

4.) Perché m.put ("primo", a) funziona? Poiché sto passando la variabile primitiva e la mappa put() accetta solo Oggetto. Quindi è a causa di boxing automatico?

Answer 1

1.) Questo collegamento suggerisce che internamente (dal compilatore) m.put ("first", a); sta convertendo in m.put ("first", Integer.valueOf (a));

(In questo esempio, c'è una List-ArrayList e qui Map-TreeMap ... FYI). allora perché l'editor dà avvertimento? E cosa dovrei fare? qual è il modo ottimizzato?

Sì, il compilatore sa che m.put("first", a) accetta solo oggetti e quindi applica autoboxing. In termini di prestazioni, l'utilizzo di autoboxing o scrittura Integer.valueOf(a) non farebbe alcuna differenza.

D'altra parte, new Integer(a) non è molto più lento di Integer.valueOf(a). La differenza è che per valori assoluti di piccole dimensioni (il valore predefinito è compreso tra -128 e 127) Integer.valueOf(a) utilizzerà una cache, cioè non creerà nuovi oggetti per tutto il tempo. Per tutti gli altri valori invoca comunque lo new Integer(a).

Esempio:

Integer.valueOf(1) == Integer.valueOf(1) si produrrà vero
Integer.valueOf(1000) == Integer.valueOf(1000) produrrà falsa
new Integer(1) == new Integer(1) sarà resa falsa, come la cache non è qui usato

2.) Se invece di Map, se c'è qualche struttura dati come HashTable quindi ???

Perché lo chiedi? C'è HashTable ma dal momento che è sincronizzato significa più overhead rispetto a HashMap, quindi a meno che non sia necessario il bastone di sincronizzazione su HashMap o TreeMap se è necessario l'ordinamento.

3.) Perché l'editor restituisce Ineger una box non necessaria.

E 'probabilmente solo a causa di leggibilità (a è più breve di Integer.valueOf(a)).

4.) Perché m.put ("first", a) funziona? Perché sto passando la variabile primitiva e la mappa put() accetta solo Object. Quindi è a causa del pugilato automatico?

Vedere 1

Answer 2

4.) Perché m.put ("first", a) funziona? Perché sto passando la variabile primitiva e la mappa put() accetta solo Object.

Autoboxing.

int vengono convertiti automaticamente in Integer e viceversa (con possibile NullPointerException in questo caso)

3.) Perché editore dà la boxe Inutile Integer.

Perché non è necessario scrivere questo pezzo di codice. Il compilatore lo farà per te.

Di solito è più leggibile

2.) Se invece di mappa, se non v'è alcuna struttura di dati come HashTable, poi caso è lo stesso ???

Sì nelle raccolte JDK funziona solo con Oggetti. Significa che i tipi primitivi devono essere inscatolati. Ha un piccolo costo di runtime e un sovraccarico di memoria enorme. Un intero prende ~ 300% di memoria in più rispetto a un int.

Non puoi scappare. L'unico modo per evitare il sovraccarico del pugilato è usare raccolte specializzate come GNU trove che forniscono una classe per tipo primitivo. Utile solo se si prevede di memorizzare milioni di elementi primitivi in ​​una raccolta.

E infine mai scrivere mai un nuovo numero intero (x). Integer.valueOf (x) fa la stessa cosa ma mantiene una cache interna per evitare di creare nuove istanze per alcuni valori comunemente usati.