En 2024, nous avons analysé de nombreux projets et partagé nos découvertes sur notre blog. C'est maintenant le réveillon du Nouvel An : il est temps de raconter des histoires festives?! Nous avons rassemblé les erreurs Java les plus intrigantes détectées dans les projets open source et vous les présentons désormais !
Avant-propos
Nous avons longtemps maintenu la tradition de publier les bugs les plus intéressants détectés avec PVS-Studio, mais il n'y a pas eu de top lié à Java depuis 2020 ! Cette fois, j'ai essayé de ressusciter la rubrique vintage. J'espère que vous avez une couverture douillette et une tasse de thé chaude à portée de main, car j'ai sélectionné plus de 10 insectes amusants rien que pour vous. Voici comment ils ont été classés?:
- mon avis personnel;
- un historique intéressant du bug?;
- diversité, crédibilité et non-trivialité.
Préparez-vous pour 10 histoires divertissantes avec leur propre sagesse de programmation?: le réveillon du Nouvel An arrive bient?t après tout?:)
10ème place. Retour vers le futur
En dixième place, le premier extrait de code nous accueille à bras ouverts.
public Builder setPersonalisation(Date date, ....) { .... final OutputStreamWriter out = new OutputStreamWriter(bout, "UTF-8"); final DateFormat format = new SimpleDateFormat("YYYYMMdd"); out.write(format.format(date)); .... }
Je n'ai pas pu m'empêcher de l'inclure dans le top du réveillon car un bug dans ce code nous permet de voyager plus rapidement vers l'année suivante :) Devinez d'où vient le bug ?
Jetons un coup d'?il à l'argument passé au constructeur SimpleDateFormat. Cela semble-t-il valable ? Si on y passe presque n'importe quelle date, comme la date de rédaction de cet article (12/10/2024), le code renverra la valeur correcte, 20241210.
Cependant, si nous dépassons le 29/12/2024, il renverra 20251229 à la place, passant ainsi ingénieusement au début de la nouvelle année. Au fait, voyager dans le temps est également faisable.
Cela se produit parce que le caractère Y dans l'argument de SimpleDateFormat représente l'année en fonction du numéro de la semaine. En bref, une semaine est considérée comme la première lorsqu'elle comprend au moins quatre jours de la nouvelle année. Ainsi, si notre semaine commence un dimanche, nous pouvons entrer dans la nouvelle année trois jours plus t?t.
Pour résoudre ce problème, remplacez simplement un Y majuscule par un y minuscule. Vous voulez en savoir plus ? Nous avons consacré un article entier à ce sujet.
Voici un avertissement PVS-Studio pour cette erreur?:
V6122 L'utilisation du modèle ? Y ? (semaine année) a été détectée?: il était probablement prévu d'utiliser ? y ? (année). SkeinParameters.java 246
En raison des spécificités du numéro de semaine, les tests ne sont donc pas le meilleur ami pour trouver cette erreur. Alors pourquoi un bug aussi actuel arrive-t-il en dernier lieu ? La raison est que l'avertissement ne provient pas de la version actuelle de Bouncy Castle mais de notre base de tests. Les anciennes sources restent toujours là, et ce bug est corrigé depuis longtemps. C'est un tel salut du passé, juste un nouveau voyage dans le temps :)
9ème place. "?a ne semble pas fonctionner"
En neuvième place, nous avons l'avertissement de l'analyse GeoServer?:
@Test public void testStore() { Properties newProps = dao.toProperties(); // .... Assert.assertEquals(newProps.size(), props.size()); for (Object key : newProps.keySet()) { Object newValue = newProps.get(key); Object oldValue = newProps.get(key); // <= Assert.assertEquals(newValue, oldValue); } }
Voici l'avertissement PVS-Studio?:
V6027 Les variables 'newValue', 'oldValue' sont initialisées via l'appel à la même fonction. Il s'agit probablement d'une erreur ou d'un code non optimisé. DataAccessRuleDAOTest.java 110, DataAccessRuleDAOTest.java 111
Qu'est-ce qu'il y a d'intéressant dans une telle erreur ? Laissez-moi vous révéler ce qui se cache derrière les quatre points?:
public Builder setPersonalisation(Date date, ....) { .... final OutputStreamWriter out = new OutputStreamWriter(bout, "UTF-8"); final DateFormat format = new SimpleDateFormat("YYYYMMdd"); out.write(format.format(date)); .... }
Il y a un commentaire indiquant que le code ne fonctionne pas pour une raison quelconque. Honnêtement, ?a m'a fait rire la première fois que je l'ai vu.
Le commentaire est cependant plut?t ambigu. Il est probable que le test ait été écrit de cette fa?on intentionnellement pour éviter un échec alors que la comparaison est en baisse. Cependant, le code est dans cet état depuis plus d’une décennie, ce qui soulève certaines questions. Cette ambigu?té est la raison pour laquelle je ne le classe pas plus haut.
8ème place. Une balle dans le pied
Si nous ne pouvons pas appeler les bugs de JBullet des coups dans le pied, je ne sais pas lesquels nous pouvons appeler ainsi. Voici une erreur de l'article?:
@Test public void testStore() { Properties newProps = dao.toProperties(); // .... Assert.assertEquals(newProps.size(), props.size()); for (Object key : newProps.keySet()) { Object newValue = newProps.get(key); Object oldValue = newProps.get(key); // <= Assert.assertEquals(newValue, oldValue); } }
Je pense que nous n'avons même pas besoin de l'avertissement PVS-Studio pour repérer où se trouve l'erreur. Quoi qu'il en soit, juste au cas où, le voici?:
V6026 Cette valeur est déjà affectée à la variable 'proxy1'. HashedOverlappingPairCache.java 233
Oui, c'est une erreur d'une simplicité embarrassante. Cette simplicité le rend encore plus hilarant. Néanmoins, il a sa propre histoire.
La bibliothèque JBullet est un portage de la bibliothèque Bullet C/C, et il y a une fonction similaire ici?:
@Test public void testStore() { Properties newProps = dao.toProperties(); // properties equality does not seem to work... Assert.assertEquals(newProps.size(), props.size()); for (Object key : newProps.keySet()) { Object newValue = newProps.get(key); Object oldValue = newProps.get(key); Assert.assertEquals(newValue, oldValue); } }
Il est facile de voir que ce code est écrit correctement. à en juger par le blame de git, il est initialement écrit correctement. Il s'avère que l'erreur s'est produite lorsque le code a été porté d'une langue à une autre.
Pour sa simplicité frappante associée à une histoire riche, j'attribue à cet avertissement la huitième place. J'espère que vous avez apprécié le fait que le bug de la balle dans le pied s'est avéré être lié au C.
7ème place. Même les grands mathématiciens font des erreurs
Certes, le prochain avertissement me réchauffe le c?ur pour plusieurs raisons. Voici un extrait de code de la vérification GeoGebra?:
@Override public BroadphasePair findPair(BroadphaseProxy proxy0, BroadphaseProxy proxy1) { BulletStats.gFindPairs++; if (proxy0.getUid() > proxy1.getUid()) { BroadphaseProxy tmp = proxy0; proxy0 = proxy1; proxy1 = proxy0; } .... }
Essayez de trouver l'erreur vous-même?! Pour vous empêcher de jeter un coup d'?il, j'ai caché l'avertissement et l'explication dans un spoiler.
V6107 La constante 0,7071067811865 est utilisée. La valeur résultante pourrait être inexacte. Pensez à utiliser Math.sqrt(0.5). DrawAngle.java 303 En réalité, 0,7071067811865 n'est pas un nombre magique, c'est simplement le résultat arrondi de la racine carrée de 0,5. Mais à quel point cette perte de précision est-elle critique ? GeoGebra est un logiciel con?u pour les mathématiciens, et une précision supplémentaire ne semble pas faire de mal. Pourquoi est-ce que j'aime tant ce bug ? Tout d'abord, lors des conférences, je demande souvent aux participants de trouver une erreur similaire dans d'autres fragments de code. Les regarder analyser attentivement le code lorsque le bug est dissimulé dans une constante a toujours été amusant. Deuxièmement, il s'agit de ma première règle de diagnostic implémentée pour l'analyseur Java. C'est pourquoi je n'ai pas pu m'empêcher de l'inclure en haut – même en étant conscient des préjugés – je l'ai mis à la septième place :)La réponse
Tout d'abord, regardons l'avertissement de PVS-Studio?:
6ème place. Ce modèle ne fonctionne pas
L'avertissement suivant, que j'ai tiré du premier article basé sur la vérification DBeaver, n'attirera peut-être pas immédiatement notre attention. Voici un fragment de code?:
public Builder setPersonalisation(Date date, ....) { .... final OutputStreamWriter out = new OutputStreamWriter(bout, "UTF-8"); final DateFormat format = new SimpleDateFormat("YYYYMMdd"); out.write(format.format(date)); .... }
Voici ce que l'analyseur PVS-Studio a détecté?:
V6082 Verrouillage non sécurisé à double vérification. Le champ doit être déclaré comme volatile. TaskImpl.java 59, TaskImpl.java317
Bien qu'il n'y ait rien de spécial à propos de cet avertissement particulier, je le trouve toujours très intriguant. Le fait est que le modèle de verrouillage à double vérification appliqué ne fonctionne pas. Quelle est l'astuce ? C'était pertinent il y a 20 ans :)
Si vous souhaitez en savoir plus sur le sujet, je vous suggère de lire l'article complet. Mais pour l'instant, permettez-moi de vous donner un bref résumé.
Le modèle de verrouillage à double vérification est utilisé pour implémenter une initialisation retardée dans des environnements multithread. Avant le contr?le ? lourd ?, le contr?le ? léger ? est exécuté sans bloc de synchronisation. La ressource n'est créée que lorsque les deux vérifications réussissent.
Cependant, dans cette approche, la création d'objets est non atomique et le processeur et le compilateur peuvent modifier le ordre d'opération. Ainsi, un autre thread peut accidentellement recevoir un objet partiellement créé et commencer à travailler avec lui, ce qui peut entra?ner un comportement incorrect. Cette erreur peut rarement se produire, le débogage sera donc un énorme défi pour les développeurs.
Voici une variante?: ce modèle n'a pas fonctionné jusqu'au JDK 5. à partir du JDK 5, le mot-clé volatile a été introduit pour résoudre le problème potentiel de réorganisation des opérations grace au principe arrive-avant. L'analyseur nous prévient que nous devons ajouter ce mot-clé.
Cependant, il serait préférable d’éviter ce schéma de toute fa?on. Les performances du matériel et de la JVM ont beaucoup progressé depuis, et les opérations synchronisées ne sont plus aussi lentes. Cependant, une mauvaise mise en ?uvre du modèle DCL reste un piège courant, avec les conséquences potentiellement graves décrites ci-dessus. Cela confirme le fait que notre analyseur trouve encore de telles erreurs de négligence dans les anciens projets.
5ème place. Micro-optimisation
La cinquième place revient à un autre avertissement DBeaver auquel nous avons consacré un article. Jetons-y un coup d'oeil?:
@Test public void testStore() { Properties newProps = dao.toProperties(); // .... Assert.assertEquals(newProps.size(), props.size()); for (Object key : newProps.keySet()) { Object newValue = newProps.get(key); Object oldValue = newProps.get(key); // <= Assert.assertEquals(newValue, oldValue); } }
Voici une explication?:
V6030 La méthode située à droite de l'opérateur '&' sera appelée quelle que soit la valeur de l'opérande de gauche. Il est peut-être préférable d'utiliser ? && ?. ExasolTableColumnManager.java 79, DB2TableColumnManager.java 77
Le développeur a mélangé le && logique avec le & au niveau du bit. Ils ont un comportement différent?: les conditions de l'expression ne se terminent pas après le ET au niveau du bit. L'évaluation de court-circuit ne fonctionne pas pour ET au niveau du bit. Ainsi, même si exasolTableBase != null renverra false, le thread d'exécution atteindra exasolTableBase.getClass() et mènera à un NPE.
D'accord, c'est juste une faute de frappe, passons à autre chose, d'accord ? DBeaver contient de nombreux avertissements de ce type. Beaucoup. Beaucoup sont relativement inoffensifs, mais pour les lecteurs curieux, j'ai laissé quelques exemples ci-dessous?:
ExasolConnectionManager.java?: ExasolDataSource.java?:Utiliser des opérations au niveau du bit qui n'entra?nent pas d'erreurs
ExasolSecurityPolicy.java?:
public Builder setPersonalisation(Date date, ....) {
....
final OutputStreamWriter
out = new OutputStreamWriter(bout, "UTF-8");
final DateFormat
format = new SimpleDateFormat("YYYYMMdd");
out.write(format.format(date));
....
}
@Test
public void testStore() {
Properties newProps = dao.toProperties();
// ....
Assert.assertEquals(newProps.size(), props.size());
for (Object key : newProps.keySet()) {
Object newValue = newProps.get(key);
Object oldValue = newProps.get(key); // <=
Assert.assertEquals(newValue, oldValue);
}
}
@Test
public void testStore() {
Properties newProps = dao.toProperties();
// properties equality does not seem to work...
Assert.assertEquals(newProps.size(), props.size());
for (Object key : newProps.keySet()) {
Object newValue = newProps.get(key);
Object oldValue = newProps.get(key);
Assert.assertEquals(newValue, oldValue);
}
}
Après avoir creusé plus profondément, mon équipe a supposé que les développeurs auraient pu essayer de micro-optimiser les performances. Pour une image complète, vous pouvez consulter notre article – ici, je présente un résumé.
Le point clé est que les opérations au niveau du bit ne reposent pas sur des prédictions de branche, ce qui permet potentiellement une exécution plus rapide par rapport aux opérations logiques.
à notre grande surprise, une référence locale soutient cette affirmation?:
Le tableau illustre le temps requis pour chaque type d'opération. Si nous lui faisons confiance, les opérations au niveau du bit semblent être 40?% plus rapides que les opérations logiques.
Pourquoi est-ce que j'aborde ce sujet ? Mettre en évidence le co?t des micro-optimisations potentielles.
Tout d'abord, les développeurs ont inventé la prédiction de branche pour une raison?: il serait trop co?teux de l'abandonner. Ainsi, le benchmark fonctionne probablement plus rapidement car les valeurs ont une distribution normale, ce qui est peu susceptible d'être observé dans des cas réels.
Deuxièmement, l'abandon du mécanisme d'évaluation des courts-circuits peut entra?ner des co?ts considérablement plus élevés. Si nous regardons le troisième exemple du spoiler ci-dessus, nous pouvons voir que l'opération contain la plus rapide ne s'exécutera pas tout le temps au lieu de s'arrêter rapidement.
Troisièmement, nous donnons carte blanche pour de telles erreurs dès le début du chapitre.
Dans l’ensemble, je trouve le récit édifiant du prix de la micro-optimisation suffisamment convaincant pour ouvrir notre top cinq.
4ème place. Le test n'échouera pas s'il ne fonctionne pas
Les tests automatisés sont souvent considérés comme la garantie ultime contre diverses erreurs. Cependant, de temps en temps, je suis tenté de demander : ? Qui teste les tests lui-même ? Un autre avertissement de la vérification GeoServer le démontre une fois de plus. Voici un fragment de code?:
@Override public BroadphasePair findPair(BroadphaseProxy proxy0, BroadphaseProxy proxy1) { BulletStats.gFindPairs++; if (proxy0.getUid() > proxy1.getUid()) { BroadphaseProxy tmp = proxy0; proxy0 = proxy1; proxy1 = proxy0; } .... }
L'avertissement PVS-Studio?:
V6060 La référence 'e' a été utilisée avant d'être vérifiée par rapport à null. ResourceAccessManagerWCSTest.java 186, ResourceAccessManagerWCSTest.java 193
à première vue, cet avertissement peut ne pas sembler être le plus excitant de l'analyseur, car le V6060 est souvent émis pour du code redondant. Pourtant, j'ai promis de sélectionner les candidatures en fonction de leur attrait. Cette affaire est donc bien plus intéressante qu’il n’y para?t.
Au départ, la logique du test peut sembler erronée car la variable e est obtenue à partir de l'opérateur catch et reste inchangée, elle ne sera donc jamais nulle. Nous pouvons simplement effectuer une modification parasite et supprimer la branche then de la condition if(e == nul) comme inaccessible. Pourtant, ce serait radicalement faux. Avez-vous déjà compris le piège??
La clé réside dans une variable supplémentaire dans le code qui contient l'objet d'exception, c'est un soi. Sa valeur change dans le corps de la boucle. Ainsi, on peut facilement deviner que dans la condition, il devrait y avoir la variable se au lieu de e.
Cette erreur fera que la branche then ne sera jamais exécutée, nous ne saurons donc pas qu'il n'y a pas d'exception. Pire encore, il est assez difficile de remarquer une telle erreur lors d'une revue de code car les noms de variables sont terriblement similaires.
Il y a deux sagesses à tirer de cette histoire?:
- Nommez clairement les variables, même dans les tests. Sinon, il sera plus facile de commettre de telles erreurs?;
- Les tests ne suffisent pas à garantir la qualité du projet car ils peuvent aussi contenir des erreurs. Ainsi, cela laisse des failles pour les bugs au sein de l’application.
Pour avoir dispensé des le?ons aussi précieuses, j'attribue à cet avertissement la quatrième place.
3ème place. Bon débogage, les amis
Les trois premiers gagnants appartiennent à l'avertissement du chèque NetBeans. Les extraits de code précédents étaient relativement compacts, alors regardons-en un plus long?:
public Builder setPersonalisation(Date date, ....) { .... final OutputStreamWriter out = new OutputStreamWriter(bout, "UTF-8"); final DateFormat format = new SimpleDateFormat("YYYYMMdd"); out.write(format.format(date)); .... }
Pour la dernière fois, essayez de trouver le bug vous-même, j'attendrai...
Vous recherchez??
Bien ! Ceux qui ont trouvé l'erreur uniquement dans l'expression iDesc.neighbor != null || iDesc.index == iDesc.index, je suis désolé de vous dire que vous avez perdu :)
Bien s?r, il y a un problème, mais il n'est pas assez intéressant pour celui du haut. Oui, il y a deux erreurs ici, je vous ai un peu trompé. Mais que sont les vacances sans un peu de malice ? :)
L'analyseur a détecté une erreur dans l'expression i^i ici et a émis l'avertissement suivant?:
V6001 Il y a des sous-expressions identiques 'i' à gauche et à droite de l'opérateur '^'. LayoutFeeder.java 3897
L'opération XOR n'a aucun sens car le OU exclusif avec deux valeurs identiques sera toujours nul. Pour un rappel rapide, voici la table de vérité pour XOR?:
a | b | a^b |
---|---|---|
0 | 0 | 0 |
0 | 1 | 1 |
1 | 0 | 1 |
1 | 1 | 0 |
En d'autres termes, l'opération n'est vraie que lorsque les opérandes sont différents. Nous aurons tous les bits pareils, puisque la valeur est la même.
Pourquoi ai-je autant aimé ce bug?? Il existe l'opération i^1, qui semble presque identique à i^i. Ainsi, il serait incroyablement facile de rater cette erreur lors d'une révision de code, puisque nous avons déjà vu le bon i^1 ci-dessus.
Je ne sais pas vous, mais ?a me rappelle le fameux :
public Builder setPersonalisation(Date date, ....) { .... final OutputStreamWriter out = new OutputStreamWriter(bout, "UTF-8"); final DateFormat format = new SimpleDateFormat("YYYYMMdd"); out.write(format.format(date)); .... }
Sinon, il est difficile d'expliquer comment cela est entré dans le code, à moins que nous rejetions la version ennuyeuse avec une simple faute de frappe. Si vous avez réussi à repérer ce bug, félicitez-vous ou partagez vos talents de détective dans les commentaires :)
2ème place. Quand les modèles échouent
J'ai déjà montré les erreurs des premier et troisième articles de DBeaver, en sautant le deuxième. Je me trompe : ce qui suit provient uniquement du deuxième article.
L'analyseur PVS-Studio n'aime pas que isBinaryContents soit appelé depuis le constructeur de la classe TextWithOpen, qui est remplacé dans les sous-classes?:
@Test public void testStore() { Properties newProps = dao.toProperties(); // .... Assert.assertEquals(newProps.size(), props.size()); for (Object key : newProps.keySet()) { Object newValue = newProps.get(key); Object oldValue = newProps.get(key); // <= Assert.assertEquals(newValue, oldValue); } }
Et alors ? C'est annulé, mais ce n'est pas grave. Cela ressemble à une odeur de code, rien de critique. Du moins, c'est ce que je pensais. J'ai consacré un article à ma lutte contre ce bug.
TextWithOpen a de nombreuses sous-classes, et l'une d'entre elles est TextWithOpenFile. Là, la méthode est en fait remplacée, et au lieu de false, elle renvoie un champ que la superclasse n'a pas?:
@Test public void testStore() { Properties newProps = dao.toProperties(); // properties equality does not seem to work... Assert.assertEquals(newProps.size(), props.size()); for (Object key : newProps.keySet()) { Object newValue = newProps.get(key); Object oldValue = newProps.get(key); Assert.assertEquals(newValue, oldValue); } }
Encore suspect?? à quoi ressemble le constructeur de cette classe ?
@Override public BroadphasePair findPair(BroadphaseProxy proxy0, BroadphaseProxy proxy1) { BulletStats.gFindPairs++; if (proxy0.getUid() > proxy1.getUid()) { BroadphaseProxy tmp = proxy0; proxy0 = proxy1; proxy1 = proxy0; } .... }
Vous avez remarqué ?a ? Le champ binaire est initialisé après l'appel du constructeur de superclasse. Cependant, il y a un appel à la méthode isBinaryContents, qui fait référence au champ de la sous-classe !
Voici l'avertissement PVS-Studio?:
V6052 L'appel de la méthode 'isBinaryContents' remplacée dans le constructeur de classe parent 'TextWithOpen' peut conduire à l'utilisation de données non initialisées. Inspecter le champ?: binaire. TextWithOpenFile.java(77), TextWithOpen.java 59
C'est une image plut?t amusante. à première vue, le développeur semblait suivre les meilleures pratiques?: éviter les spaghettis de code, impossibles à maintenir, et essayer d'implémenter la POO canonique via un modèle de méthode modèle. Mais même en mettant en ?uvre un modèle aussi simple, nous pouvons commettre une erreur, et c’est ce qui s’est produit. à mon avis, une telle beauté (fallacieuse) dans la simplicité est une solide deuxième place.
1ère place. Une erreur en compense une autre
Réjouissez-vous ! La première place sur scène ! La concurrence était rude, mais il fallait faire un choix. Après de longues délibérations, j'ai décidé de prendre en compte l'avertissement de la vérification NetBeans. Permettez-moi de vous présenter l'extrait de code final?:
public Builder setPersonalisation(Date date, ....) { .... final OutputStreamWriter out = new OutputStreamWriter(bout, "UTF-8"); final DateFormat format = new SimpleDateFormat("YYYYMMdd"); out.write(format.format(date)); .... }
Je suis convaincu qu'il est impossible de repérer un tel bug d'un seul coup d'?il, à moins, bien s?r, que vous ayez commis cette erreur vous-même. Je ne vous ferai pas attendre, voici l'avertissement PVS-Studio?:
V6009 La capacité du tampon est définie sur ??47?? à l'aide d'une valeur de caractère. Très probablement, le symbole ??/?? était censé être placé dans le tampon. IgnorerUnignoreCommand.java 107
En fait, l'erreur est ridiculement élémentaire : le constructeur StringBuilder n'a pas de surcharge qui accepte les caractères. Quel constructeur est alors appelé ? Le développeur pensait apparemment qu'une surcharge acceptant String serait appelée, et que la valeur initiale de StringBuilder serait alors cette barre oblique.
Cependant, une conversion de type implicite se produit et le constructeur de type qui accepte int est appelé. Dans notre cas, il représente la taille initiale de StringBuilder. Passer char comme argument n’affecte fonctionnellement rien car il ne sera pas inclus dans la cha?ne finale. Si la taille initiale est dépassée, elle augmentera simplement d'elle-même sans provoquer d'exceptions ni d'autres effets secondaires.
Mais attendez, j'ai mentionné deux erreurs, n'est-ce pas?? Où est le deuxième et comment sont-ils connectés?? Pour repérer cela, nous devrons lire le corps de la méthode et comprendre ce que fait ce code.
Il génère un chemin absolu vers un fichier ou un répertoire. D'après le code, le chemin résultant devrait ressembler à ceci?:
- pour un fichier : /folder1/file
- pour un répertoire : /folder1/folder/.
Le code semble tout à fait correct. C'est le problème. Le code fonctionne vraiment comme il se doit :) Mais si nous corrigeons l'erreur en rempla?ant un caractère par une cha?ne, nous obtiendrons ceci au lieu du résultat correct?:
- /dossier1/fichier/;
- /dossier1/dossier//
En d’autres termes, nous aurons une barre oblique supplémentaire à la fin de la cha?ne. Ce sera à la fin car le code ci-dessus ajoute à chaque fois un nouveau texte au début de la ligne.
Par conséquent, la deuxième erreur est que cette barre oblique a été transmise au constructeur comme argument. Cependant, je ne sous-estimerais pas une telle erreur car si quelqu'un décide de remplacer un caractère par une cha?ne sans vérifier, il peut y avoir des problèmes.
C'est ainsi que la première place dans le top des erreurs revient au code qui fonctionne correctement. Les miracles du Nouvel An, à quoi vous attendiez-vous ? :)
Conclusion
J'espère que vous avez aimé lire mes histoires de bugs. Si une histoire particulière vous a marqué – ou si vous avez des suggestions d'ajustements au classement – ??n'hésitez pas à partager vos impressions dans les commentaires, je les garderai en tête pour la prochaine fois :)
Si d'autres langages vous intéressent, je vous invite à consulter les principaux bugs C# pour 2024 ici?: restez à l'écoute pour les nouveaux tops?!
Toutes ces erreurs ont été détectées avec l'analyseur PVS-Studio, et la dernière version (7.34) vient de sortir ! Vous pouvez l'essayer par ce lien.
Pour rester à l'affut des nouveaux articles sur la qualité du code, nous vous invitons à vous abonner?:
- PVS-Studio X (Twitter);
- notre résumé mensuel des articles?;
Bonne année?!
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Outils d'IA chauds

Undress AI Tool
Images de déshabillage gratuites

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Clothoff.io
Dissolvant de vêtements AI

Video Face Swap
échangez les visages dans n'importe quelle vidéo sans effort grace à notre outil d'échange de visage AI entièrement gratuit?!

Article chaud

Outils chauds

Bloc-notes++7.3.1
éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

Java prend en charge la programmation asynchrone, y compris l'utilisation de la transition complète, des flux réactifs (tels que ProjectActor) et des threads virtuels dans Java19. 1.COMPLETABLEFUTURE Améliore la lisibilité et la maintenance du code à travers les appels de cha?ne et prend en charge l'orchestration des taches et la gestion des exceptions; 2. ProjectAacteur fournit des types de mono et de flux pour implémenter une programmation réactive, avec mécanisme de contre-pression et des opérateurs riches; 3. Les fils virtuels réduisent les co?ts de concurrence, conviennent aux taches à forte intensité d'E / S et sont plus légères et plus faciles à développer que les fils de plate-forme traditionnels. Chaque méthode a des scénarios applicables, et les outils appropriés doivent être sélectionnés en fonction de vos besoins et les modèles mixtes doivent être évités pour maintenir la simplicité

En Java, les énumérations conviennent à représenter des ensembles constants fixes. Les meilleures pratiques incluent: 1. Utilisez ENUM pour représenter l'état fixe ou les options pour améliorer la sécurité et la lisibilité des types; 2. Ajouter des propriétés et des méthodes aux énumérations pour améliorer la flexibilité, telles que la définition des champs, des constructeurs, des méthodes d'assistance, etc.; 3. Utilisez Enuummap et Enumset pour améliorer les performances et la sécurité des types car ils sont plus efficaces en fonction des tableaux; 4. évitez l'abus des énumérations, tels que des valeurs dynamiques, des changements fréquents ou des scénarios logiques complexes, qui doivent être remplacés par d'autres méthodes. L'utilisation correcte de l'énumération peut améliorer la qualité du code et réduire les erreurs, mais vous devez faire attention à ses limites applicables.

Javanio est un nouvel IOAPI introduit par Java 1.4. 1) s'adresse aux tampons et aux canaux, 2) contient des composants de tampon, de canal et de sélecteur, 3) prend en charge le mode non bloquant et 4) gère les connexions simultanées plus efficacement que l'OI traditionnel. Ses avantages se reflètent dans: 1) IO non bloquant les réductions de la surcharge du thread, 2) le tampon améliore l'efficacité de transmission des données, 3) le sélecteur réalise le multiplexage et 4) la cartographie de la mémoire accélère la lecture et l'écriture de la lecture de fichiers. Remarque Lorsque vous utilisez: 1) le fonctionnement FLIP / clair du tampon est facile à confondre, 2) les données incomplètes doivent être traitées manuellement sans blocage, 3) l'enregistrement du sélecteur doit être annulé à temps, 4) Nio ne convient pas à tous les scénarios.

HashMap implémente le stockage de paires de valeurs clés via des tables de hachage en Java, et son noyau réside dans les emplacements de données de positionnement rapidement. 1. Utilisez d'abord la méthode HashCode () de la clé pour générer une valeur de hachage et la convertir en un index de tableau via les opérations de bit; 2. Différents objets peuvent générer la même valeur de hachage, entra?nant des conflits. à l'heure actuelle, le n?ud est monté sous la forme d'une liste liée. Après JDK8, la liste liée est trop longue (longueur par défaut 8) et elle sera convertie en arbre rouge et noir pour améliorer l'efficacité; 3. Lorsque vous utilisez une classe personnalisée comme clé, les méthodes equals () et hashcode () doivent être réécrites; 4. Hashmap élargit dynamiquement la capacité. Lorsque le nombre d'éléments dépasse la capacité et se multiplie par le facteur de charge (par défaut 0,75), se développez et remaniez; 5. Hashmap n'est pas en file et concu doit être utilisé dans multithread

Les énumérations Java représentent non seulement des constantes, mais peuvent également encapsuler le comportement, transporter des données et implémenter des interfaces. 1. L'énumération est une classe utilisée pour définir des instances fixes, telles que la semaine et l'état, ce qui est plus s?r que les cha?nes ou les entiers; 2. Il peut transporter des données et des méthodes, telles que passer des valeurs à travers les constructeurs et fournir des méthodes d'accès; 3. Il peut utiliser Switch pour gérer différentes logiques, avec une structure claire; 4. Il peut implémenter des interfaces ou des méthodes abstraites pour faire des comportements différenciés de différentes valeurs d'énumération; 5. Faites attention à éviter les abus, la comparaison du code dur, la dépendance à l'égard des valeurs ordinales et la dénomination raisonnable et la sérialisation.

Le modèle de conception Singleton en Java garantit qu'une classe n'a qu'une seule instance et fournit un point d'accès global via des constructeurs privés et des méthodes statiques, ce qui convient au contr?le de l'accès aux ressources partagées. Les méthodes de mise en ?uvre incluent: 1. Chargement paresseux, c'est-à-dire que l'instance n'est créée que lorsque la première demande est demandée, ce qui convient aux situations où la consommation de ressources est élevée et pas nécessairement requise; 2. Traitement à filetage, garantissant qu'une seule instance est créée dans un environnement multi-thread par des méthodes de synchronisation ou le verrouillage à double vérification et la réduction de l'impact des performances; 3. Le chargement affamé, qui initialise directement l'instance pendant le chargement des cours, convient aux objets ou scénarios légers qui peuvent être initialisés à l'avance; 4. La mise en ?uvre de l'énumération, en utilisant l'énumération Java pour soutenir naturellement la sérialisation, la sécurité des filetages et prévenir les attaques réfléchissantes, est une méthode concise et fiable recommandée. Différentes méthodes de mise en ?uvre peuvent être sélectionnées en fonction des besoins spécifiques

Facultatif peut clairement exprimer les intentions et réduire le bruit du code pour les jugements nuls. 1. Facultatif. Par exemple, lors de la prise de valeurs des cartes, Orelse peut être utilisée pour fournir des valeurs par défaut, afin que la logique soit plus claire et concise; 2. Utilisez des cartes d'appels de cha?ne pour atteindre les valeurs imbriquées pour éviter en toute sécurité le NPE, et terminer automatiquement si un lien est nul et renvoie la valeur par défaut; 3. Le filtre peut être utilisé pour le filtrage conditionnel, et les opérations ultérieures ne continueront à être effectuées que si les conditions sont remplies, sinon elle sautera directement à Orelse, qui convient au jugement commercial léger; 4. Il n'est pas recommandé de surutiliser facultatif, tels que des types de base ou une logique simple, ce qui augmentera la complexité, et certains scénarios reviendront directement à NU.

La solution de contournement principale pour la rencontre de Java.io.NotSerializableException est de s'assurer que toutes les classes qui doivent être sérialisées implémentent l'interface sérialisable et de vérifier le support de sérialisation des objets imbriqués. 1. Ajouter des ouvrages ImplementSerialisables à la classe principale; 2. Assurez-vous que les classes correspondantes de champs personnalisées de la classe implémentent également sérialisables; 3. Utilisez transitoire pour marquer les champs qui n'ont pas besoin d'être sérialisés; 4. Vérifiez les types non sérialisés dans les collections ou les objets imbriqués; 5. Vérifiez quelle classe n'implémente pas l'interface; 6. Considérez la conception de remplacement pour les classes qui ne peuvent pas être modifiées, telles que la sauvegarde des données clés ou l'utilisation de structures intermédiaires sérialisables; 7. Envisagez de modifier
