Rückgabetyp von getId() für ein Thread-Objekt

Question

Warum gibt z. B. Thread.currentThread().getId() eine lange zurück?

Muss das wirklich 64 Bits sein? Wie ich werde jemals eine Maschine haben, die diese Anzahl von Threads laufen lässt!

Ernsthaft, es ist ein bisschen ein Schmerz, da ich etwas schreibe, das eine Spur von Thread-Bezeichnern zusammen mit anderen Bits behält, und ich würde wirklich lieber nicht eine so lange Nummer verwenden müssen, sonst den eindeutigen Schlüssel, den ich habe zu erzeugen ist enorm.

Vielleicht gibt es eine Konvention über die lange Rückkehr; wie die ersten 48 Bits sind immer Null. Ich hatte eine Ausgrabung im Internet, habe aber nichts gefunden. Ich hoffe es; Weiß jemand das sicher?

Danke.

Answer 1

Dieser Code:

private static synchronized long nextThreadID() { 
    return ++threadSeqNumber; 
} 

sollte Einblick geben, warum. Im Wesentlichen werden Thread-IDs durch einen laufenden Zähler zugewiesen. Wenn Sie Ihre JVM nicht für eine signifikante Zeitspanne beenden, würde diese Zahl über die Länge gehen. Ich kann mir nur vorstellen, dass sie es getan haben, um die Wahrscheinlichkeit von Kollisionen in langen laufenden Threads zu reduzieren.

Answer 2

Java-Anwendungen sind im Vergleich zu anderen Java-Anwendungen sandboxed, was bedeutet, dass Thread-IDs wahrscheinlich kollidieren.

Threads sind nicht für alle Anwendungen eindeutig, sie sind nur für jede Anwendung eindeutig. Mit Blick auf die Thread.init Methode in der Quelle, können Sie finden:

private static synchronized long nextThreadID() { 
    return ++threadSeqNumber; 
} 

/* For generating thread ID */ 
private static long threadSeqNumber; 

Ich denke, es verwendet einen potentiellen Überlauf Fehler zu verhindern. Wenn Threads erstellt werden, würde die Nummer schließlich überlaufen. Lange wird nur

9223372036854775807(Max long value) - 2147483647(Max int value) = 9.223372e+18 

ein bisschen mehr sicher :)