Quand devrais-je utiliser des primitives au lieu d'emballer des objets?

Question

En fait, ici est un sujet similaire avec peu de valeur pratique. Autant que je sache, les primitives fonctionnent mieux et doivent être utilisées partout, sauf dans les cas où des fonctionnalités liées à l'objet (par exemple, la vérification null ) sont nécessaires. Droit?

Answer 1

N'oubliez pas que, comme créer un nouvel emballage pour chaque événement de boxe coûte assez cher, en particulier étant donné qu'il est généralement utilisé dans un seul périmètre de méthode, La sélection automatique utilise un pool de wrappers courants.

Il s’agit en fait d’une implémentation de modèle de conception flyweight . Lorsqu'une boxe survient pour une valeur connue, au lieu de créer une nouvelle instance d'encapsuleur, une instance pré-créée est extraite d'un pool et renvoyée.

Une conséquence est la suivante: l'utilisation de la substitution automatique pour les calculs scientifiques n'est toujours pas recommandée . Par exemple, le code d = a * b + c utilise les classes Integer pour a, b, c et d et le code généré est d.valueOf (a.intValue () * b.intValue () + c.intValue ( )). Toutes ces invocations de méthodes ont leur propre surcharge. Par conséquent, il est généralement recommandé d’utiliser la sélection automatique en cas de nécessité pour stocker des primitives dans des collections .

Et même dans ce cas, si vous disposez d'une énorme collection d'entiers enveloppants, les frais généraux peuvent être plus longs, jusqu'à 20 fois plus longs , comme rapporté dans cet article .

Jb ajoute ce commentaire important:

  

De plus, Wrapper.valueOf (primitive) utilise un pool de wrappers. Préférez donc Integer.valueOf (5) au nouvel Integer (5)

Answer 2

Les primitives sont plus rapides lorsqu'elles sont utilisées , car les objets doivent être décapsulés avant d'être utilisés. il y a donc une étape supplémentaire que la VM doit effectuer. Par exemple, pour effectuer un calcul arithmétique sur un entier, celui-ci doit d'abord être converti en int avant que l'arithmétique puisse être effectuée.

Dans de nombreuses applications métier, cela compte probablement rarement. Mais si vous écrivez quelque chose de très lourd, comme par exemple un processeur de transformation graphique, vous êtes bien plus susceptible de vous en soucier.

Answer 3

oui, les primitives sont plus rapides que les objets. Depuis Java 5, vous pouvez même mélanger des primitives et des objets sans les convertir manuellement. Le mécanisme de substitution automatique prend soin de cela.

Cela signifie que si vous placez une primitive dans une collection, le compilateur ne se plaindra pas et convertira la primitive en objet de manière implicite.

Answer 4

Si vous avez besoin de stocker des primitives dans des collections, vous pouvez utiliser les primitives-communes .

Je préfère utiliser des primitives pour les wrappers, seul le lieu qui doit absolument avoir des wrappers sont des classes d'entités. Les bases de données supportent les valeurs NULL, donc les entités devraient aussi.

J'ai déjà travaillé sur un projet utilisant des primitives (et homebrew ORM) dans l'accès à une base de données:

 class Foo{
    int xxx = -1;
 ...
 }

Et puis vous avez eu:

 void persist(Foo foo){
     ...
     statement.setInt(15,foo.getXXX()==-1?null:foo.getXXX());
     ...
}

Dieu c'était mal.

Answer 5

Je dirais que vous ne devriez craindre d'utiliser des primitives sur des wrappers que lorsque vous profilez votre application et que vous voyez que la sélection automatique est un problème de performances ou de mémoire. Selon mon expérience, la mémoire devient un problème avant les cycles du processeur lorsqu’on parle de primitives par rapport aux objets de wrapping.