Warum/Wenn Sie nicht möchten, dass Java 8 UseStringDeduplication aktiviert in die JVM?

Java 8 eingeführt String Deduplication, die aktiviert werden können durch starten der JVM mit -XX:+UseStringDeduplication Möglichkeit geboten, etwas Speicher sparen, indem Verweise auf ähnliche String Objekte anstatt zu halten Duplikate. Natürlich ist es die Wirksamkeit variiert von Programm zu Programm je nach Auslastung der Strings aber ich denke, es ist sicher zu sagen, dass im Allgemeinen kann es als vorteilhaft für die meisten Anwendungen (wenn nicht alle) macht mich Wunder über einige Dinge:

Warum ist es nicht standardmäßig aktiviert? Ist es wegen der Kosten, die im Zusammenhang mit dedeuplication oder einfach, weil G1GC ist noch als neu?

Gibt es (oder gab es) eine beliebige Kante Fällen, in denen Sie nicht wollen, um Verwendung der Deduplizierung?

Ich denke, es ist (wie Sie bereits erraten haben) in Erster Linie die Laufzeit, die Kosten der de-Duplikation.
Nicht die G1GC, aber die de-Duplizierung selbst könnte als neu.

InformationsquelleAutor Ninetou | 2017-02-07

27

Fällen, wo die Zeichenfolge de-Duplizierung könnte schädlich sind:
- Es gibt viele Streicher, aber eine sehr geringe Wahrscheinlichkeit von Duplikaten: die Zeit-overhead, der auf der Suche nach Duplikaten und der Speicherplatz-overhead des de-duping-Daten-Struktur würde nicht zurückgezahlt werden.
- Gibt es eine angemessene Wahrscheinlichkeit von Duplikaten, aber die meisten strings sterben innerhalb von ein paar GC-Zyklen¹ sowieso. Die de-Duplizierung ist weniger vorteilhaft, wenn die de-hinters Licht geführt Saiten waren, GC ' ed eh bald.
  
  (Dies ist nicht über die Saiten, dass Sie nicht überleben die ersten GC-Zyklus. Es würde keinen Sinn machen, für die GC, um auch versuchen de-dup Saiten, dass es weiß, dass es Müll.)
Können wir nur spekulieren, warum das Java-team wiederum nicht auf de-duping standardmäßig, aber Sie sind in einer viel besseren position, um rationale (d.h. auf Fakten basierend) Entscheidungen auf das, was du und ich. Mein Verständnis ist, dass Sie haben Zugang zu vielen großen real-world-Anwendungen für das benchmarking /ausprobieren der Wirkungen von Optimierungen. Sie können auch Kontakte in partner-oder Kunden-Organisationen mit ähnlich großen code-Basen und der Sorge um die Effizienz ... wer kann Sie bitten, für feedback, ob Optimierungen in einer early-access-Version wie erwartet funktioniert.

^{1 - Dies ist abhängig vom Wert des StringDeduplicationAgeThreshold

JVM-Einstellung. Voreingestellt ist der Wert 3 bedeutet, dass (in etwa) eine Zeichenfolge, um zu überleben 3 kleine Sammlungen oder eine große Sammlung für de-duping. Aber jedenfalls, wenn eine Zeichenfolge der de-hinters Licht geführt und dann festgestellt, nicht erreichbar sein, kurz danach, der de-duping Gemeinkosten werden nicht zurückgezahlt für die Zeichenkette.}

Wenn Sie sich Fragen, wenn Sie sollten erwägen Sie das aktivieren der de-duping, mein Rat wäre, es zu versuchen und sehen, ob es hilft auf einer basis pro Anwendung. Aber Sie tun müssen, einige application-level-benchmarking (dies braucht Anstrengung!) um sicher zu sein, dass die de-duping ist von Vorteil ...

Einer sorgfältigen Lesen der JEP 192 würde auch helfen, Sie verstehen, die Probleme, und ein Urteil über, wie Sie möglicherweise gelten für Ihre Java-Anwendung.
- Der 2. Fall ist nicht vollständig wahr. Als es nur deduplicates Streicher, der überlebt, 3 GCs. Ich fand diese Seite eine gute Lektüre zu diesem Thema java-performance.info/java-string-deduplication
- Wenn ein string überlebt GCs 3, de-hinters Licht geführt und dann nicht erreichbar ist, kurz danach die de-duping Gemeinkosten wird nicht wieder hereingeholt werden. Das war mein Punkt.
- ist das bedeutet, dass alle de-hinters Licht geführt zu teuer wäre für verschwendet wegen String-erste GC-ed? Sorry für die über das Jahr die Frage von mir.
- Ja. Das ist das, was ich sage. Natürlich ist dies nur ein mögliches Szenario. In anderen, der string ist lange gelebt-und die Kosten der de-duping wird wieder hereingeholt, möglicherweise um ein Vielfaches.
InformationsquelleAutor Stephen C

Ich absolut verstehen, dass dies keine Antwort auf die Frage, wollte nur erwähnen, dass die jdk-9 stellt eine weitere Optimierung ist standardmäßig eingeschaltet genannt :

-XX:+CompactStrings

wo Latin1 Zeichen belegen ein byte anstelle von zwei (mit einem char). Deshalb ändern viele interne Methoden der String geändert haben - Sie tun das gleiche für den Benutzer, aber intern sind Sie schneller in eine Menge von Fällen.

Auch im Falle von Strings für die Verkettung von zwei Zeichenfolgen zusammen über das plus-Zeichen das javac wird, produzieren unterschiedliche bytecode.

Gibt es keine bytecode-Instruktion, die zwei Zeichenfolgen verkettet zusammen, so dass die javac generiert

StringBuilder#Anhängen

in der back-end. Bis jdk-9.

Nun der bytecode Delegierten

StringConcatFactory#makeConcatWithConstants

oder

StringConcatFactory#makeConcat

über der invokedynamic bytecode-Instruktion:

   aload_0
   1: aload_2
   2: aload_1
   3: invokedynamic #8,  0 //InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
   8: areturn

Wie die zwei Zeichenfolgen verkettet werden, ist eine Laufzeit-Entscheidung. es könnte noch ein StringBuilder oder es könnte eine Verkettung von byte-arrays, etc. Alles, was Sie wissen, dass dies kann sich ändern, und Sie erhalten die Schnellste mögliche Lösung.

BEARBEITEN

Habe ich gerade ausgetestet und sah, dass es eine ganze Menge von Strategien, wie diese Strings Anhängen:

    private enum Strategy {
    /**
     * Bytecode generator, calling into {@link java.lang.StringBuilder}.
     */
    BC_SB,

    /**
     * Bytecode generator, calling into {@link java.lang.StringBuilder};
     * but trying to estimate the required storage.
     */
    BC_SB_SIZED,

    /**
     * Bytecode generator, calling into {@link java.lang.StringBuilder};
     * but computing the required storage exactly.
     */
    BC_SB_SIZED_EXACT,

    /**
     * MethodHandle-based generator, that in the end calls into {@link java.lang.StringBuilder}.
     * This strategy also tries to estimate the required storage.
     */
    MH_SB_SIZED,

    /**
     * MethodHandle-based generator, that in the end calls into {@link java.lang.StringBuilder}.
     * This strategy also estimate the required storage exactly.
     */
    MH_SB_SIZED_EXACT,

    /**
     * MethodHandle-based generator, that constructs its own byte[] array from
     * the arguments. It computes the required storage exactly.
     */
    MH_INLINE_SIZED_EXACT
}