この回答は、当時のオペレーティング システムで実行されていた当時の Sun JDK が実際に行ったことの観点から、2011 年に書かれました。それはずっと前だった!leventov's answerは、より最新の視点を提供します。
その投稿は間違っており、nanoTime
安全です。この投稿には、Sun のリアルタイムおよび同時実行の担当者であるDavid Holmes によるブログ投稿へのリンクがあるコメントがあります。それは言います:
System.nanoTime() は、QueryPerformanceCounter/QueryPerformanceFrequency API を使用して実装されます [...] QPC によって使用されるデフォルトのメカニズムは、ハードウェア アブストラクション レイヤー (HAL) によって決定されます [...] このデフォルトは、ハードウェア全体だけでなく、OS 全体でも変更されますバージョン。たとえば、Windows XP Service Pack 2 では、プロセッサ タイムスタンプ カウンター (TSC) ではなく電源管理タイマー (PMTimer) を使用するように変更されました。これは、TSC が SMP システムの異なるプロセッサで同期されないという問題と、その頻度によるものです。電源管理設定に基づいて変化する可能性があります (したがって、経過時間との関係)。
したがって、Windows では、これはWinXP SP2 までは問題でしたが、現在はありません。
他のプラットフォームについて説明しているパート II (またはそれ以上) は見つかりませんが、その記事には、Linux が同じ問題に遭遇し、同じ方法で解決したというコメントが含まれており、clock_gettime(CLOCK_REALTIME) の FAQへのリンクが含まれています。 、それは言う:
- すべてのプロセッサ/コアで clock_gettime(CLOCK_REALTIME) は一貫していますか? (arch は重要ですか? 例: ppc、arm、x86、amd64、sparc)。
バグがあると見なされるか、バグがあると見なされます。
ただし、x86/x86_64 では、同期されていない、または可変周波数の TSC が時間の不一致を引き起こす可能性があります。2.4 カーネルはこれに対する保護がまったくなく、初期の 2.6 カーネルもここではうまく機能しませんでした。2.6.18 以降では、これを検出するロジックが改善されており、通常は安全なクロックソースにフォールバックします。
ppc には常に同期されたタイムベースがあるため、問題になることはありません。
したがって、Holmes のリンクが をnanoTime
呼び出すことを暗示していると解釈できる場合clock_gettime(CLOCK_REALTIME)
、x86 上のカーネル 2.6.18 の時点で、常に PowerPC 上で安全に動作します (Intel とは異なり、IBM と Motorola は実際にマイクロプロセッサの設計方法を知っているため)。
悲しいことに、SPARC や Solaris についての言及はありません。そしてもちろん、IBM JVM が何をするのかはわかりません。しかし、最新の Windows および Linux 上の Sun JVM では、これが正しく行われます。
編集:この回答は、引用元に基づいています。しかし、それが実際には完全に間違っているのではないかと心配しています。いくつかの最新情報は本当に価値があります。Linux の時計に関する 4 年前の新しい記事へのリンクを見つけました。これは役に立つかもしれません。