Java-Programmiersprache
Java ist eine objektorientierte Programmiersprache, die plattformübergreifende Anwendungssoftware schreiben kann. Es handelt sich um eine Java-Programmiersprache und Java-Plattform, die im Mai 1995 von Sun Microsystems eingeführt wurde. der allgemeine Name von JavaEE(j2ee), JavaME(j2me), JavaSE(j2se)).
Die folgenden Fragen gelten als fortgeschrittener und werden in Vorstellungsgesprächen selten gestellt, da sie den Interviewer möglicherweise abschrecken. Aber Sie können Zeit finden, es selbst zu üben.
1. System.exit(0) überspringt die Ausführung des „finally“-Blocks
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"); }
Warum wird dieser Code im „finally“-Block ausgegeben? Warum wird der Stacktrace nicht gedruckt?
2. String str = „Hallo“; wobei str ein String-Objekt ist. Anders als in C++ sind Variablen entweder Basistypen oder Referenzen. Variablen können keine Objekte sein. Das bedeutet, dass Ausdrücke wie dieser:
String str = "Hello"; String text = "Bye"; str == text; // 比较两个引用,而不是内容 str = text; // 把text的引用赋值给str
In den meisten Fällen gibt es keinen wirklich großen Unterschied, aber diese Schreibweise kann zu Verwirrung führen.
final StringBuilder sb = new StringBuidler(); sb.append("Hello"); // 这个引用是final类型的,而不是这个实例。 method(sb); // 可以通过方法来修改这个实例,不过这个变量是无法修改的
3. Java-Speicherlecks sind dasselbe, was C++-Programmierer verstehen.
Die Definition von Speicherlecks auf Wikipedia lautet: „In der Informatik bedeutet dies, dass ein Programm nicht ordnungsgemäß verwaltet wird Wenn bei der objektorientierten Programmierung nicht auf ein Objekt im Speicher zugegriffen werden kann, handelt es sich um einen Speicherverlust. In Java sind Objekte jedoch immer erreichbar Referenzen werden gelöscht. Der Begriff „Speicherverlust“ bedeutet in Java, dass sich Objekte im Speicher befinden, die nicht existieren sollten, normalerweise einige Ressourcen, die nicht mehr verwendet werden, aber dennoch in der Sammlung gespeichert sind.
4. Multithread-Programmierung ist schwierig
Multithread-Programmierung ist in der Tat schwierig, wenn Sie keine Erfahrung haben. Wenn Sie einfach eine Menge Code zur Ausführung in eine Reihe von Threads werfen, gibt es keine Möglichkeit, das Problem zu lösen, und es wird nur ein Durcheinander sein. Wenn Sie jedoch Threads nach Bedarf zuweisen, die Interaktion zwischen Threads steuern und einige einfache Muster verwenden können, die die Mitglieder des Teams verstehen können, wird das Problem viel einfacher. Eine weitere Herausforderung besteht natürlich darin, dass man jeden im Team dazu bringen muss, seine Regeln zu befolgen :-)
Machen Sie sich keine Sorgen über die Leistungsunterschiede zwischen verschiedenen Operationen
Das habe ich kürzlich gehört Es besteht das Problem darin, Ganzzahlen, Speicherzugriff, Modulo und Ausgabe zur Konsole hinzuzufügen. Obwohl jede dieser Operationen um eine Größenordnung langsamer ist als die vorherige, wollte dieser Typ einfach die schnellste Operation optimieren, hinzufügen und durch einige teurere Operationen ersetzen. Wenn Sie die Leistung wirklich optimieren möchten, sollten Sie diese teuren Vorgänge besser durch einen kostengünstigen Vorgang ersetzen. Wenn Ihr Engpass beispielsweise in der Hardware liegt, müssen Sie eine große Anzahl von Dateien von der Festplatte lesen und den Softwarecode ändern . Es nützt nichts, weil das Problem überhaupt nicht da ist.
6. Zufallszahlen sind zufällig
Eine bestimmte Menge von Zufallszahlen ist wie ein bestimmtes Zahlenmuster. Ich habe dieses Problem bereits in diesem Artikel angesprochen. Viele Menschen glauben nicht, dass die von Zufallszahlengeneratoren generierten Zahlen nicht wirklich zufällig sind.
7. Gleitkommazahlen sollten vermieden werden, da sie zufällige Fehler erzeugen können.
Bei derselben Operation erzeugen Gleitkommazahlen jedes Mal den gleichen Fehler. Fehler sind vorhersehbar und daher kontrollierbar. Wenn Sie wissen, was Sie tun wollen, und sich an einige einfache Regeln wie das Runden des Ergebnisses halten, werden Sie mit einer Gleitkommazahl nicht mehr falsch machen als mit einer BigDecimal-Zahl, und außerdem ist sie besser lesbar, robuster und leistungsfähiger als hundertmal schneller (und erzeugt gleichzeitig weniger Müllobjekte).
8. Zeitzonen sind ewig
Der Grund für dieses Missverständnis ist, dass sich Zeitzonen mit der Zeit ändern. Das bedeutet, dass Europa/London im neuen Zeitalter der 1.1.1970 um 01:00 Uhr statt um 00:00 Uhr ist. Warum? Denn zwischen 1968 und 1971 galt in London die Sommerzeit.
In den letzten Jahren haben sich auch viele Zeitzonen geändert. Früher war Moskau der östliche 3. Bezirk (GMT+3), aber jetzt ist es der östliche 4. Bezirk (GMT+4) (ab 27. März 2011). Wenn Sie sich die Zeit im Jahr 2010 ansehen, werden Sie feststellen, dass es sich um den östlichen 3. Bezirk und nicht um den östlichen 4. Bezirk handelt.
Es gibt noch etwas, das für Sie vielleicht überraschend klingt:
Der Februar in Schweden im Jahr 1721 hatte 30 Tage.
Der erste Tag in England im Jahr 1751 war der 25. März, also 11 Tage hinter Frankreich.
Nachdem die Vereinigten Staaten den gregorianischen Kalender eingeführt hatten, ging er Hunderte von Jahren zurück, sodass die ursprünglich aufgezeichneten Daten durch zwei Kalender dargestellt werden konnten (normalerweise werden zwei Daten gleichzeitig angegeben, um eine höhere Genauigkeit zu gewährleisten). Beispielsweise wurde der Geburtstag von George Washington vom 11. Februar 1731 auf den 22. Februar 1732 geändert.
9. Wenn Sie eine nichtflüchtige Variable in einem Thread lesen, können Sie schließlich ihren aktualisierten Wert lesen.
Diese Frage erschien vor ein paar Tagen zweimal auf StackOverflow. Wenn der JIT-Compiler den Code optimiert, werden im Allgemeinen die nichtflüchtigen Felder inline, die von diesem Thread nicht geändert wurden. Sobald dieser Code kompiliert ist (Sie können ihn über -XX:+PrintCompilation sehen), werden die Änderungen, die Sie in einem anderen Thread an diesem Feld vornehmen, wahrscheinlich nie mehr sichtbar sein. Das Hinzufügen zufälliger Synchronisationsblöcke oder Druckanweisungen kann die Ausführung dieser Optimierung verzögern oder den JIT-Compiler verwirren, sodass er diese Optimierung nicht durchführt.
10. Java-Interviewfragen sind alle korrekt
Viele Java-Interviewfragen sind entweder veraltet (wurden seit mehr als 10 Jahren nicht mehr aktualisiert und entsprechen nicht der aktuellen Java-Version). oder sind für jeden irreführend, vielleicht sogar falsch. Leider werden diese Antworten ungeprüft herumgereicht.
Ich werde auf die Antworten auf Stackoverflow verweisen, da die Antworten hier besser von Experten begutachtet werden. Verwenden Sie im Allgemeinen keine Websites wie Rose India. Die Qualität der obigen Antworten ist lächerlich schlecht. Wenn Sie tiefer in die Materie eintauchen möchten, können Sie einen Blick darauf werfen, wie viele Rechtschreibfehler (Klassennamen und Fachbegriffe) oder falsche Angaben im obigen Artikel enthalten sind. Ein Grund für diese Probleme ist, dass es keinen wirksamen Feedback-Mechanismus zur Korrektur dieser Fehler gibt.
Das Obige ist der Inhalt von 10 Lügen über Java. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!