System.nanoTime () tamamen işe yaramaz mı?

Blog yayınında belgelendiği gibi Java System.nanoTime () sakının x86 sistemlerde, Java'nın System.nanoTime () bir kullanarak zaman değerini döndürür CPU belirli sayacı. Şimdi bir çağrının zamanını ölçmek için kullandığım aşağıdaki durumu göz önünde bulundurun:

long time1= System.nanoTime();
foo();
long time2 = System.nanoTime();
long timeSpent = time2-time1;

Şimdi çok çekirdekli bir sistemde, zamanı1 ölçtükten sonra, iş parçacığı sayacı önceki CPU'dan daha az olan farklı bir işlemciye programlanmış olabilir. Böylece time2'de time1'den daha az bir değer elde edebiliriz . Böylece timeSpent'te negatif bir değer elde ederiz.

Bu durum düşünüldüğünde, System.nanotime şimdilik şimdilik işe yaramaz değil mi?

Sistem zamanının değiştirilmesinin nanotim süresini etkilemediğini biliyorum. Yukarıda tarif ettiğim sorun bu değil. Sorun, her CPU'nun açıldığından beri farklı bir sayaç tutmasıdır. Bu sayaç ikinci CPU'da birinci CPU'ya göre daha düşük olabilir. İş parçacığı time1 aldıktan sonra işletim sistemi tarafından ikinci CPU'ya programlanabildiğinden, timeSpent değeri yanlış ve hatta negatif olabilir.

Bu cevap, 2011 yılında, zamanın işletim sistemlerinde çalışan Sun JDK'nın gerçekte ne yaptığı konusunda yazılmıştır. Çok uzun zaman önceydi! leventov'un cevabı daha güncel bir bakış açısı sunuyor.

Bu yazı yanlış ve nanoTimegüvende. Sun hakkında, Sun'da gerçek zamanlı ve eşzamanlı bir adam olan David Holmes'un bir blog yayınına bağlantı veren bir yorum var . Diyor ki:

System.nanoTime (), QueryPerformanceCounter / QueryPerformanceFrequency API'sini kullanarak uygulanır [...] QPC tarafından kullanılan varsayılan mekanizma Donanım Soyutlama katmanı (HAL) tarafından belirlenir [...] Bu varsayılan yalnızca donanımda değil, aynı zamanda işletim sisteminde de değişir sürümleri. Örneğin, Windows XP Service Pack 2, TSC'nin SMP sistemlerindeki farklı işlemcilerde eşitlenmemesi ve sıklığı nedeniyle işlemci zaman damgası sayacı (TSC) yerine güç yönetimi zamanlayıcısını (PMTimer) kullanmak için bazı şeyleri değiştirdi güç yönetimi ayarlarına bağlı olarak değişebilir (ve dolayısıyla geçen zamanla ilişkisi).

Yani, Windows üzerinde, bu oldu WinXP SP2 kadar bir sorun, ama şimdi değil.

Diğer platformlar hakkında konuşan bir bölüm II (veya daha fazla) bulamıyorum, ancak bu makalede Linux'un aynı sorunla karşılaştığı ve aynı şekilde çözdüğü ve saat_gettime (CLOCK_REALTIME) ile ilgili SSS bağlantısıyla bir açıklama var diyor ki:

1. Clock_gettime (CLOCK_REALTIME) tüm işlemciler / çekirdekler arasında tutarlı mı? (Arch önemli mi? Örn. Ppc, kol, x86, amd64, sparc).

Bu should veya hatalı olarak kabul edilir.

Ancak, x86 / x86_64'te, senkronize edilmemiş veya değişken frekans TSC'lerinin zaman tutarsızlıklarına neden olduğunu görmek mümkündür. 2.4 çekirdeklerin buna karşı hiçbir koruması yoktu ve 2.6 çekirdek de burada çok iyi sonuç vermedi. 2.6.18'den itibaren bunu tespit mantığı daha iyidir ve genellikle güvenli bir saat kaynağına geri döneriz.

ppc her zaman senkronize edilmiş bir zaman tabanına sahiptir, bu yüzden bir sorun olmamalıdır.

Holmes'ın bağlantısı bu nanoTimeçağrıları ima etmek olarak okunabiliyorsa clock_gettime(CLOCK_REALTIME), o zaman x86'da 2.6.18 çekirdeği ve her zaman PowerPC'de güvenlidir (çünkü Intel'in aksine, Intel ve Motorola mikroişlemcilerin nasıl tasarlanacağını biliyorlar).

Ne yazık ki SPARC veya Solaris'ten bahsedilmiyor. Ve elbette, IBM JVM'lerinin ne yaptığı hakkında hiçbir fikrimiz yok. Ancak modern Windows ve Linux'taki Sun JVM'leri bunu doğru yapıyor.

EDIT: Bu cevap alıntı yaptığı kaynaklara dayanmaktadır. Ama yine de aslında tamamen yanlış olabileceğinden endişeleniyorum. Bazı daha güncel bilgiler gerçekten değerli olacaktır. Linux'un saatleri hakkında faydalı olabilecek dört yıllık daha yeni bir makaleye bağlantıya geldim .

Biraz araştırma yaptım ve eğer bilgiçlik taslayan bir şey varsa, o zaman evet işe yaramaz olarak düşünülebilir ... belirli durumlarda ... ihtiyaçlarınızın ne kadar hassas olduğuna bağlı ...

Java Sun sitesinden bu alıntıya göz atın :

Gerçek zamanlı saat ve System.nanoTime () aynı sistem çağrısını ve dolayısıyla aynı saati temel alır.

Java RTS ile, tüm zaman tabanlı API'ler (örneğin, Zamanlayıcılar, Periyodik Konular, Son Tarih İzleme ve benzeri) yüksek çözünürlüklü zamanlayıcıya dayanır. Ve gerçek zamanlı önceliklerle birlikte, gerçek zamanlı kısıtlamalar için uygun kodun doğru zamanda yürütülmesini sağlayabilirler. Buna karşılık, sıradan Java SE API'leri, belirli bir zamanda yürütme garantisi olmadan yüksek çözünürlüklü süreleri yönetebilen birkaç yöntem sunar. Geçen zaman ölçümlerini gerçekleştirmek için koddaki çeşitli noktalar arasında System.nanoTime () kullanılması her zaman doğru olmalıdır.

Java'nın ayrıca nanoTime () yöntemi için bir uyarısı vardır :

Bu yöntem yalnızca geçen süreyi ölçmek için kullanılabilir ve diğer sistem veya duvar saati zamanı kavramlarıyla ilgili değildir. Döndürülen değer, sabit ama keyfi bir zamandan beri nanosaniyeyi temsil eder (belki de gelecekte, bu nedenle değerler negatif olabilir). Bu yöntem nanosaniye hassasiyet sağlar, ancak mutlaka nanosaniye doğruluğu sağlamaz. Değerlerin ne sıklıkta değiştiği konusunda hiçbir garanti verilmez. Yaklaşık 292,3 yıldan (2 ⁶³ nanosaniye) daha uzun süren ardışık çağrılardaki farklılıklar, sayısal taşma nedeniyle geçen süreyi doğru bir şekilde hesaplamayacaktır.

Çıkarılabilecek tek sonuç, nanoTime () 'a doğru bir değer olarak güvenilemeyeceğidir. Bu nedenle, sadece nano saniye aradaki zamanları ölçmeniz gerekmiyorsa, sonuçta elde edilen döndürülen değer negatif olsa bile bu yöntem yeterince iyidir. Ancak, daha yüksek hassasiyete ihtiyacınız varsa, JAVA RTS kullanmanızı tavsiye ediyorlar.

Sorunuzu cevaplamak için ... hiçbir nanoTime () işe yaramaz değil .... her durumda kullanmak için en ihtiyatlı yöntem değildir.

Tartışmaya gerek yok, sadece kaynağı kullanın. Burada, Linux için SE 6, kendi sonuçlarınızı verin:

jlong os::javaTimeMillis() {
  timeval time;
  int status = gettimeofday(&time, NULL);
  assert(status != -1, "linux error");
  return jlong(time.tv_sec) * 1000  +  jlong(time.tv_usec / 1000);
}


jlong os::javaTimeNanos() {
  if (Linux::supports_monotonic_clock()) {
    struct timespec tp;
    int status = Linux::clock_gettime(CLOCK_MONOTONIC, &tp);
    assert(status == 0, "gettime error");
    jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp.tv_nsec);
    return result;
  } else {
    timeval time;
    int status = gettimeofday(&time, NULL);
    assert(status != -1, "linux error");
    jlong usecs = jlong(time.tv_sec) * (1000 * 1000) + jlong(time.tv_usec);
    return 1000 * usecs;
  }
}

Java 7'den beri, System.nanoTime()JDK belirtimi ile güvenli olduğu garanti edilmektedir. System.nanoTime()Javadoc , bir JVM (yani, tüm iş parçacıkları arasında) içinde gözlemlenen tüm çağrıların monotonik olduğunu açıkça ortaya koymaktadır:

Döndürülen değer, sabit ancak keyfi bir başlangıç ​​zamanından bu yana nanosaniyeyi temsil eder (belki de gelecekte, bu nedenle değerler negatif olabilir). Aynı kaynak, Java sanal makinesinin bir örneğinde bu yöntemin tüm çağrıları tarafından kullanılır; diğer sanal makine örneklerinin farklı bir başlangıç ​​noktası kullanması muhtemeldir.

JVM / JDK uygulaması, temel OS yardımcı programları çağrıldığında gözlemlenebilecek tutarsızlıkları gidermekten sorumludur (örneğin, Tom Anderson'ın cevabında belirtilenler) ).

Bu soruya verilen diğer eski cevapların çoğu (2009-2012'de yazılmıştır), muhtemelen Java 5 veya Java 6 için geçerli olan ancak artık Java'nın modern sürümleri için geçerli olmayan FUD'yi ifade etmektedir.

Bununla birlikte, JDK garantilerinin nanoTime()güvenliğine rağmen , OpenJDK'da belirli platformlarda veya belirli koşullarda bu garantiyi desteklememesini sağlayan birkaç hata olduğunu belirtmek gerekir (örn. JDK-8040140 , JDK-8184271 ). Şu nanoTime()anda OpenJDK wrt'de açık (bilinen) hatalar yok , ancak yeni bir hatanın keşfedilmesi veya daha yeni bir OpenJDK sürümünde bir gerileme kimseyi şok etmemelidir.

Bunu göz önünde bulundurarak, zamanlanmış engelleme, aralık bekleme, zaman aşımları, vb. İçin kullanılan kod, nanoTime()tercihen negatif zaman farklarını (zaman aşımları) istisnalar yerine sıfırlar olarak ele almalıdır. O tüm sınıflarda tüm zamanlanmış bekleme yöntemlerinin davranışları ile tutarlı olduğu için bu uygulama da tercih edilebilir java.util.concurrent.*, örneğin Semaphore.tryAcquire(), Lock.tryLock(),BlockingQueue.poll() vb

Bununla birlikte, nanoTime()zamanlanmış engelleme, aralık bekleme, zaman aşımları vb. Uygulamak için yine de tercih edilmelidir, currentTimeMillis()çünkü ikincisi "geriye doğru giden zaman" fenomenine (örn. Sunucu zaman düzeltmesi nedeniyle) tabidir, yani currentTimeMillis()zaman aralıklarını ölçmek için uygun değildir hiç. Bu cevaba bakın fazla bilgi için .

nanoTime()Doğrudan kod yürütme süresi ölçümlerinde kullanmak yerine, tercihen duvar saati profili oluşturma modunda JMH ve async-profiler gibi özel kıyaslama çerçeveleri ve profiller kullanılmalıdır .

Feragatname: Bu kütüphanenin geliştiricisiyim

Bunu daha iyi isteyebilirsiniz:

http://juliusdavies.ca/nanotime/

Ancak bir DLL veya Unix .so (paylaşılan nesne) dosyasını geçerli kullanıcının ana dizinine kopyalar, böylece JNI'yi çağırabilir.

Bazı arka plan bilgileri sitemde:

http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html

Linux, CPU'lar arasındaki tutarsızlıkları düzeltir, ancak Windows yapmaz. System.nanoTime () işlevinin yalnızca yaklaşık 1 mikro saniye hassasiyette olduğunu varsayalım. Daha uzun bir zamanlama elde etmenin basit bir yolu, foo () 1000 veya daha fazlasını çağırmak ve zamanı 1000'e bölmektir.

Kesinlikle işe yaramaz. Zamanlama meraklıları çok çekirdekli sorunu doğru bir şekilde gösteriyor, ancak gerçek sözcük uygulamalarında genellikle currentTimeMillis () 'den radikal olarak daha iyi.

Çerçeve yenilemelerindeki grafik konumlarını hesaplarken nanoTime (), programımda ÇOK daha yumuşak harekete yol açar.

Ve sadece çok çekirdekli makinelerde test ediyorum.

System.nanoTime () kullanarak bildirilen negatif geçen süreyi gördüm . Açık olmak gerekirse, söz konusu kod:

    long startNanos = System.nanoTime();

    Object returnValue = joinPoint.proceed();

    long elapsedNanos = System.nanoTime() - startNanos;

ve 'elapsedNanos' değişkeninin negatif bir değeri vardı. (Ara aramanın 293 yıldan daha az sürdüğünden de eminim, bu da uzun süre depolanan nanolar için taşma noktasıdır :)

Bu, AIX çalıştıran IBM P690 (çok çekirdekli) donanımda bir IBM v1.5 JRE 64bit kullanılarak meydana geldi. Bu hatanın sadece bir kez oluştuğunu gördüm, bu yüzden çok nadir görünüyor. Nedenini bilmiyorum - bu donanıma özgü bir sorun mu, bir JVM hatası mı - bilmiyorum. Ayrıca genel olarak nanoTime () 'in doğruluğu için ne anlama geldiğini bilmiyorum.

Orijinal soruyu cevaplamak için nanoTime'ın işe yaramaz olduğunu düşünmüyorum - milisaniyenin altında bir zamanlama sağlıyor, ancak dikkate almanız gereken yanlış (sadece teorik değil) gerçek bir risk var.

Bu, Windows XP ve JRE 1.5.0_06 çalıştıran Core 2 Duo için bir sorun gibi görünmüyor.

Üç iş parçacıklı bir testte System.nanoTime () 'ın geriye doğru gittiğini görmüyorum. İşlemciler hem meşgul, hem de dişler etrafta hareket eden iplikleri kışkırtmak için ara sıra uyuyor.

[EDIT] Bunun yalnızca fiziksel olarak ayrı işlemcilerde gerçekleştiğini, yani sayaçların aynı kalıpta birden çok çekirdek için senkronize edildiğini tahmin ediyorum.

Hayır, değil ... Sadece CPU'nuza bağlı, Yüksek Hassasiyetli Etkinlik Zamanlayıcısını kontrol edin şeylerin CPU'ya göre nasıl farklı şekilde / neden tedavi edildiğini öğrenmek için .

Temel olarak, Java'nızın kaynağını okuyun ve sürümünüzün işlevle ne yaptığını kontrol edin ve CPU'ya karşı çalışıyorsa, üzerinde çalışacaksınız.

IBM , performans karşılaştırması (2008 tarihli ancak güncellenmiş) için bile kullanmanızı önerir .

Peter Lawrey'in iyi bir cevap verdiği aynı tartışmanın temelini oluşturuyorum. Neden System.nanoTime () kullanarak negatif geçen bir zaman alıyorum?

Birçok kişi Java System.nanoTime () içinde negatif zaman dönebileceğini belirtti. Başkalarının söylediklerini tekrarladığı için özür dilerim.

1. nanoTime () bir saat değil, CPU döngü sayacıdır.
2. Dönüş değeri zamana benzemek için frekansa bölünür.
3. CPU frekansı dalgalanabilir.
4. İş parçacığınız başka bir CPU'da zamanlandığında, nanoTime () alma şansı vardır ve bu da negatif bir farkla sonuçlanır. Bu mantıklı. CPU'lar arasındaki sayaçlar senkronize edilmez.
5. Çoğu durumda, oldukça yanıltıcı sonuçlar elde edebilirsiniz, ancak delta negatif olmadığından söyleyemezsiniz. Bunu düşün.
6. (onaylanmadı) Talimatlar yeniden sıralanırsa, aynı CPU'da bile olumsuz bir sonuç alabileceğinizi düşünüyorum. Bunu önlemek için, talimatlarınızı serileştiren bir bellek bariyeri çağırmanız gerekir.

System.nanoTime () çalıştırıldığı yerde coreID döndürürse çok iyi olurdu.

Java çapraz platformdur ve nanoTime platforma bağlıdır. Java kullanıyorsanız - nanoTime kullanmadığınız zaman. Bu işlevle farklı jvm uygulamalarında gerçek hatalar buldum.

Java 5 belgeleri de bu yöntemin aynı amaçla kullanılmasını önerir.

Bu yöntem yalnızca geçen süreyi ölçmek için kullanılabilir ve başka herhangi bir sistem veya duvar saati zamanı kavramıyla ilgili değildir.

Java 5 API Belgesi

Ayrıca, System.currentTimeMillies()sistem saatinizi değiştirdiğinizde değişir, ancak System.nanoTime()değişmez, böylece ikincisi süreleri ölçmek için daha güvenlidir.

nanoTimezamanlama için son derece güvensizdir. Temel öncelik test algoritmaları üzerinde denedim ve aynı girdi için tam anlamıyla bir saniye arayla cevaplar verdi. Bu saçma yöntemi kullanmayın. Zaman milisinden daha doğru ve kesin bir şeye ihtiyacım var, ama o kadar da kötü değil nanoTime.