Ich habe versucht, alles über Java-Optimierungen herauszufinden und etwas Interessantes gefunden.
Erster Fall: primitive Art der Kompilierzeitoptimierung
%Vor% Nach der Kompilierung (ich verwende jd-gui-0.3.5.windows um Binärdateien zu dekompilieren) sieht es so aus:
Wie erwartet, nicht wahr? i wurde nach dem Kompilieren durch seinen Wert ersetzt (Inlining-Optimierung). Also habe ich erwartet, etwas Ähnliches zu sehen, nachdem primitiver Typ durch seinen Wrapper ersetzt wurde, aber ...
Zweiter Fall: Nicht-primitive Art der Kompilierzeitoptimierung
%Vor%Nach der Kompilierung:
%Vor% Was ist Clazz.this in diesem Zusammenhang? Ich weiß, dass es sich um eine umschließende Instanz von Clazz handelt, aber in diesem Fall sollte es nicht funktionieren! Ich muss i drucken, aber der Compiler schlägt mir vor, Clazz.this zu drucken, und es funktioniert! Was ist das Problem? Wird jd-gui falsch dekompiliert oder fehlt etwas bei der Java-Kompilierung und -Optimierung?
UPD:
Inhalt von Class :
Wird
jd-guifalsch dekompiliert oder fehlt etwas bei der Java-Kompilierung und -Optimierung?
jd-gui dekompiliert den Code falsch.
Auf meiner JVM sieht der disassemblierte Code für die anonyme Klasse wie folgt aus:
%Vor% Wie Sie sehen, ist eine Kopie von i in der anonymen Klasse im Feld val$i gespeichert (der Name ist implementierungsspezifisch).
Dieses Feld scheint Ihr Decompiler fälschlicherweise als Clazz.this darzustellen.
Es sollte ein nächster Ansatz sein, bei dem jd-gui fehlschlägt, wie Integer -Objekt seinen Wert out-boxt, wenn System.out.println aufgerufen wurde. Der Dekompilierungsalgorithmus selbst muss annehmen, was der wichtigste Verweis auf dieses Integer -Objekt ist, und er wählt das Ergebnis von Clazz.this .
Tags und Links compilation java optimization