Lequel utiliser, int ou Integer

Question

Je dois créer un objet de transfert de données que je vais utiliser pour stocker les enregistrements extraits de la base de données. Dans cet objet de transfert de données, je dois déclarer un champ numérique. Pour ce que l'on est meilleur - int ou entier

Si je définis le champ comme Integer, cela aura-t-il un impact sur les performances en raison du type "Integer" si je vais extraire plus de 2000 enregistrements de DB!?

Merci d'avance.

Answer 1

Entier est une meilleure option, car elle peut gérer null ; pour int , null deviendrait 0 , silencieusement, si resultSet.getInt (..) est utilisé. Sinon, une exception, telle que "Il est impossible de définir null sur une propriété primitive", est générée.

La performance n’est guère préoccupante ici.

• si vous choisissez int , vous finirez par ajouter un code de traitement supplémentaire; et cela ne vous profiterait pas beaucoup. Votre code ne sera pas clair et net, beaucoup de code de plaque signalétique, et vous ne gagneriez même pas de performance.
• , laissez-moi préciser, pour les bases de données, null n’est pas égal à zéro. Parfois, vous finissez par entrer 0 , où null était prévu. Imaginons le cas où l'utilisateur a soumis un formulaire et ne fournit aucune valeur pour int . Vous finirez par obtenir 0 par défaut. Cela a du sens, ou le fait vraiment, quand ce champ est pas null dans la base de données.

Answer 2

Vous devriez vraiment prendre votre décision en fonction de ce que vous avez besoin que votre objet fasse, plutôt que des coûts liés aux performances. Décider en fonction des performances devrait être fait, une fois qu'un problème de vitesse a été identifié avec un profileur - la racine de tout le mal et de tout ça.

Examinez quelques-unes de leurs caractéristiques et utilisez-les pour prendre votre décision, par exemple

.

• Entier peut être null , int ne peut pas. Le int dans la DB est-il un champ Nullable ?
• Avez-vous besoin d'accéder aux méthodes de la classe Integer ?
• Faites-vous de l'arithmétique?

Personnellement, j'opte toujours pour la primitive sur le wrapper. Mais c’est juste une question de préférence, plutôt que de s’appuyer sur un mérite technique.

Answer 3

À mon avis, le choix entre déclarer quelque chose comme int ou Integer revient simplement à déterminer si null est une valeur valide pour cela ou non. La sélection automatique (et la boîte automatique) prennent en charge tous les problèmes de conversion dont le nombre doit être simplement d'un type ou d'un autre. Il est également peu probable que les performances (comme cela a été souligné) soient visibles dans presque tous les cas.

En outre, int devrait être le choix naturel, et sera probablement le plus performant si cela devait être un problème de toute façon. Si vous devez pouvoir stocker des valeurs NULL, vous devez utiliser Integer (et vous devez également vous assurer qu'aucune référence NULL n'est auto-décompactée pour une méthode prenant simplement des entiers, ce qui entraînera une exception NullPointerException). .

Answer 4

Entier est théoriquement plus lent que int , toutefois, l'impact sur les performances devrait être minime, sauf si vous calculez des chiffres. Les optimisations JIT réduiront également la perte de performances.

Utilisez celui qui convient le mieux à votre situation en termes de type primitif ou de type de référence.

Answer 5

int est 10 fois plus rapide qu'un entier

nous testons ce code avec la bibliothèque de performances de Jetm

int n;
EtmPoint point1 = etmMonitor.createPoint("test:objects");
for (n = 0; n < 1000000; n++) {
    Integer t = 0;
    t = 10;
    t = 11;
}

point1.collect();
EtmPoint point = etmMonitor.createPoint("test:primitives");
for (n = 0; n < 1000000; n++) {
    int t = 0;
    t = 10;
    t = 11;
}
point.collect();

etmMonitor.render(new SimpleTextRenderer());

et les résultats:
test: objets 10.184
test: primitives 1.151

Answer 6

Pour vous donner une idée, 2000 Integer ajouterait environ 0,5 ms à votre requête. Si vous devez sérialiser ces données, cela pourrait en ajouter un peu plus.

Cependant, la correction devrait venir en premier. Il ne sert à rien d'être très rapide mais faux. Vous devez tenir compte des valeurs NULL et de la façon dont vous les gérez. (Sauf si la colonne n'est PAS NULL) Vous pouvez utiliser Integer.MIN ___VALEUR ou un champ long au lieu de int et utiliser Long.MIN_VALUE pour null. Même s'il est plus grand que int, il serait quand même plusieurs fois plus petit et plus efficace qu'Integer.

Answer 7

Je suppose que cela dépend entre autres de ce que vous utilisez pour accéder à la base de données. Avec un vieux JDBC simple, vous pourriez le faire avec des int , alors qu'un ORM pourrait les convertir en silence en Entiers de toute façon. Et Integer vous permettrait de gérer nulls .

Answer 8

int est utilisé par Java pour la plupart des calculs. Integer est utilisé dans toutes les formes de collections, à l'exception des tableaux primitifs.

Utilisation de nombreux entiers temporaires avec thrash le ramasse-miettes et utilisation en arrière-plan d’un processeur non falsifiable qui entraînera des ralentissements généraux dans tous les domaines. Trop de temps temporaires détruits à la seconde feront que le CG entrera en urgence "J'ai besoin de mémoire maintenant". Mode pouvant provoquer des blocages dans les applications critiques en temps de latence (par exemple: graphiques interactifs en temps réel, contrôleurs de périphériques physiques ou communications)

Donc pour moi, si j'ai beaucoup d'appels imbriqués qui ne font pas de calcul, mais accèdent à beaucoup de collections, telles que l'utilisation de clés pour les cartes, j'utilise Integer afin d'éviter des tonnes de boxing automatique lorsque des arguments sont passés.

Si les opérations nécessitent beaucoup de maths ou sont utilisées comme compteurs de boucles ou autres opérations orientées mathématiques et ne sont pas stockées dans des collections (autres que des tableaux de primitives), j'utilise la primitive. Il en va de même pour toutes les autres primitives, à l'exception de String, qui est un objet à part entière.

Answer 9

int ne peut pas être converti en String avec toString ou (String) .

Entier peut être converti en Chaîne avec toString ou (Chaîne) et peut gérer null .

Answer 10

Si vous souhaitez rechercher une valeur null , alors Entier est préférable, mais si vous souhaitez comparer l'entier, int peut être meilleur. Dans l'exemple suivant, j'utilise les nombres entiers c = 1000 et d = 1000 et le compare retourne false, mais dans le cas de int, ils retournent true.

public class IntegerCompare {

    public static void main(String[] args) {
        int a = 1000;
        int b = 1000;

        Integer c = 1000;
        Integer d = 1000;

        if (a == b) {
            System.out.println("int Value Equals");

        }
        if (c == d) {
            System.out.println("Integer value Equals");

        } else {

            System.out.println("Integer Value Not Equals");
        }
    }
}

Answer 11

Un scénario à couvrir serait la validation.

Imaginons que nous ayons la classe suivante:

class Foo{
    @Min(value = 10)
    int val;
}

Si l'utilisateur ne fournit pas de valeur pour val dans la demande, nous obtiendrons une vilaine NumberFormatException .

Si int est remplacé par Integer , nous pouvons utiliser @NotNull et résoudre ce problème plus gracieusement.