10 mensonges sur Java

Langage de programmation Java

Java est un langage de programmation orienté objet qui peut écrire des logiciels d'application multiplateformes. Il s'agit d'un langage de programmation Java et d'une plate-forme Java lancés par Sun Microsystems en mai 1995. (C'est-à-dire que le nom général de JavaEE(j2ee), JavaME(j2me), JavaSE(j2se)).

Les questions suivantes sont relativement avancées et sont rarement posées lors des entretiens car elles peuvent refuser les personnes interrogées. Mais vous pouvez trouver le temps de le pratiquer vous-même.

1. System.exit(0) ignorera l'exécution du bloc final

System.setSecurityManager(new SecurityManager() {
        @Override
        public void checkExit(int status) {
            throw new ThreadDeath();
        }
    });
    try {
        System.exit(0);
    } finally {
        System.out.println("In the finally block");
    }

Pourquoi ce code affiche-t-il le bloc final ? Pourquoi la trace de la pile n'est-elle pas imprimée ?

2. String str = "Bonjour" ; où str est un objet chaîne Différentes du C, les variables en Java sont soit des types de base, soit des références. Les variables ne peuvent pas être des objets. Cela signifie que des expressions comme celle-ci :

String str = "Hello";
    String text = "Bye";
    str == text; // 比较两个引用，而不是内容
    str = text; // 把text的引用赋值给str

Dans la plupart des cas, il n'y aura pas vraiment de différence, mais l'écrire de cette façon peut prêter à confusion.

final StringBuilder sb = new StringBuidler();
    sb.append("Hello"); // 这个引用是final类型的，而不是这个实例。
    method(sb); // 可以通过方法来修改这个实例，不过这个变量是无法修改的

3. Les fuites de mémoire Java sont les mêmes que celles que les programmeurs C comprennent.

La définition des fuites de mémoire sur Wikipédia est "En informatique, si un programme n'est pas correctement géré. Allocation de mémoire , des fuites de mémoire se produiront. En programmation orientée objet, si un objet en mémoire n'est pas accessible dans le code, il s'agit d'une fuite de mémoire. Cependant, en Java, les objets sont toujours accessibles, et ceux qui ne le sont pas. sera effacé. Le terme fuite de mémoire en Java signifie qu'il existe des objets en mémoire qui ne devraient pas exister, généralement des ressources qui ne sont plus utilisées mais qui sont toujours stockées dans la collection.

4. La programmation multithread est difficile

La programmation multithread est en effet difficile si vous n'avez aucune expérience. Si vous jetez simplement un tas de code dans un tas de threads pour l'exécution, il n'y aura aucun moyen de résoudre le problème et ce ne sera qu'un gâchis. Mais si vous pouvez allouer des threads à la demande, contrôler l’interaction entre les threads et utiliser des modèles simples que les membres de l’équipe peuvent comprendre, le problème devient beaucoup plus simple. Bien sûr, un autre défi est que vous devez faire en sorte que tous les membres de l'équipe suivent vos règles :-)

5 Ne vous inquiétez pas des différences de performances entre les différentes opérations

J'ai récemment entendu cela. il y a Le problème implique l'ajout d'entiers, d'accès à la mémoire, de modulo et de sortie à la console. Bien que chacune de ces opérations soit d'un ordre de grandeur plus lente que la précédente, ce type voulait simplement optimiser l'opération la plus rapide, l'ajout, et la remplacer par des opérations plus coûteuses. Si vous souhaitez vraiment optimiser les performances, vous feriez mieux de remplacer ces opérations coûteuses par une opération peu coûteuse. Si votre goulot d'étranglement réside dans le matériel, par exemple, vous devez lire un grand nombre de fichiers sur le disque dur et modifier le code du logiciel. C'est inutile, car le problème n'est pas du tout là.

6. Les nombres aléatoires sont aléatoires

Un ensemble spécifique de nombres aléatoires est comme un certain modèle de nombres. J'ai déjà parlé de ce problème dans cet article. Beaucoup de gens ne croient pas que les nombres générés par les générateurs de nombres aléatoires ne soient pas réellement aléatoires.

7. Les nombres à virgule flottante doivent être évités car ils peuvent produire des erreurs aléatoires.

Pour la même opération, les nombres à virgule flottante produiront la même erreur à chaque fois. Les erreurs sont prévisibles et donc contrôlables. Si vous savez ce que vous essayez de faire et respectez quelques règles simples comme arrondir le résultat, vous ne vous tromperez pas plus avec un nombre à virgule flottante qu'avec un BigDecimal, et en plus, il est plus lisible. Il est plus robuste et plus plus de cent fois plus rapide (et génère moins d'objets indésirables).

8. Les fuseaux horaires sont éternels

La raison de ce malentendu est que les fuseaux horaires changent à mesure que l'heure change. Cela signifie que l'Europe/Londres dans la nouvelle ère est le 1/1/1970 à 01h00 au lieu de 00h00, pourquoi ? Parce que Londres a utilisé l’heure d’été entre 1968 et 1971.

Ces dernières années, de nombreux fuseaux horaires ont également changé. Autrefois GMT 3 à Moscou, aujourd'hui GMT 4 (à partir du 27 mars 2011). Si vous regardez l'époque en 2010, vous constaterez qu'il s'agit du 3ème District Est au lieu du 4ème District Est.

Il y a autre chose qui peut vous surprendre :

Février en Suède en 1721 comptait 30 jours.

Le premier jour en Angleterre en 1751 était le 25 mars, soit 11 jours de retard sur la France.

Après que les États-Unis ont adopté le calendrier grégorien, celui-ci est remonté des centaines d'années en arrière, de sorte que les dates initialement enregistrées pouvaient être représentées par deux calendriers (généralement deux dates sont fournies en même temps pour plus de précision). Par exemple, l'anniversaire de George Washington est passé du 11 février 1731 au 22 février 1732.

9. Lorsque vous lisez une variable non volatile dans un thread, vous pouvez éventuellement lire sa valeur mise à jour.

Cette question est apparue deux fois sur StackOverflow il y a quelques jours. De manière générale, lorsque le compilateur JIT optimise le code, il intègre les champs non volatiles qui n'ont pas été modifiés par ce thread. Une fois ce code compilé (vous pouvez le voir via -XX : PrintCompilation), les modifications que vous apportez à ce champ dans un autre thread ne seront probablement jamais visibles. L'ajout de blocs de synchronisation aléatoires ou d'instructions d'impression peut retarder l'exécution de cette optimisation ou perturber le compilateur JIT afin qu'il n'effectue pas cette optimisation.

10. Les questions d'entretien Java sont toutes correctes

De nombreuses questions d'entretien Java sont soit obsolètes (n'ont pas été mises à jour depuis plus de 10 ans et sont déconnectées de la version actuelle de Java), ou trompent tout le monde, peut-être même à tort. Malheureusement, ces réponses circulent sans être vérifiées.

Je ferai référence aux réponses sur Stackoverflow car les réponses ici sont mieux évaluées par les pairs. En général, n'utilisez pas de sites Web comme Rose India. La qualité des réponses ci-dessus est ridiculement mauvaise. Si vous souhaitez approfondir, vous pouvez jeter un œil au nombre de fautes d’orthographe (noms de classe et termes professionnels) ou de déclarations erronées contenues dans l’article ci-dessus. L’une des raisons de ces problèmes est qu’il n’existe aucun mécanisme de rétroaction efficace pour corriger ces erreurs.

Ce qui précède est le contenu de 10 mensonges sur Java. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !