なぜ、たとえばThread.currentThread().getId()が返されるのですか？スレッドオブジェクトのgetId（）の戻り値の型
これは本当に64ビットである必要がありますか？私はその数のスレッドを実行するマシンを持つつもりです！
スレッド識別子のトラックを他のビットと一緒に保持するものを書いているので、それはちょっと痛いです。私は実際にこのような長い番号を使用する必要はありません。生成するのは膨大です。
おそらく長いリターンで慣習があります。最初の48ビットのように常にゼロです。私はインターネット上で掘り出し物を見つけましたが、何も見つかりませんでした。そうだといい;誰も確かに知っていますか？
ありがとうございました。
このコード：
private static synchronized long nextThreadID() {
return ++threadSeqNumber;
}
が理由として洞察力を与える必要があります。本質的にスレッドIDは実行中のカウンタによって割り当てられるため、JVMをかなりの時間終了させないと、この数値は長い値を超えます。長時間実行されているスレッドでの衝突の可能性を減らすために実行したとしか想像できません。
Javaアプリケーションは他のJavaアプリケーションと比べてサンドボックス化されています。つまり、スレッドIDが衝突する可能性があります。
スレッドはすべてのアプリケーションで一意ではなく、アプリケーションごとに一意です。ソース内のThread.init方法を見ると、あなたが見つけることができます：
private static synchronized long nextThreadID() {
return ++threadSeqNumber;
}
/* For generating thread ID */
private static long threadSeqNumber;
私は潜在的なオーバーフローのバグを防ぐために使用さだと思います。スレッドが作成されると、その数は最終的にオーバーフローします。あなたが値上正確にゼロ保証を持っている限りは、単に、おそらく基礎となるオペレーティング・システムのいくつかの識別子を返しますビットより安全
9223372036854775807(Max long value) - 2147483647(Max int value) = 9.223372e+18
:)
号のgetId（）をされています。 –
未来を計画し、本当に大きな数のスレッドを許可するのは良い考えです。 – Keppil
それは彼らがそれを設計した方法なので。あなたは本当に64ビット*ポインタ*を返すケースを見落としました。建設的ではない。 – EJP