System.cienTimeMillis vs System.nanoTime

Độ chính xác Vs. Độ chính xác

Những gì tôi muốn biết là liệu tôi nên sử dụng System.civerseTimeMillis () hoặc System.nanoTime () khi cập nhật vị trí của đối tượng trong trò chơi của mình? Sự thay đổi chuyển động của họ tỷ lệ thuận với thời gian đã trôi qua kể từ cuộc gọi cuối cùng và tôi muốn chính xác nhất có thể.

Tôi đã đọc được rằng có một số vấn đề nghiêm trọng về độ phân giải thời gian giữa các hệ điều hành khác nhau (cụ thể là Mac / Linux có độ phân giải gần 1 ms trong khi Windows có độ phân giải 50ms ??). Tôi chủ yếu chạy các ứng dụng của mình trên windows và độ phân giải 50ms có vẻ không chính xác.

Có lựa chọn nào tốt hơn hai cái tôi liệt kê không?

Bất kỳ đề xuất / ý kiến?

Nếu bạn chỉ tìm kiếm các phép đo cực kỳ chính xác về thời gian đã trôi qua , hãy sử dụng System.nanoTime(). System.currentTimeMillis()sẽ cung cấp cho bạn thời gian trôi qua chính xác nhất có thể tính bằng mili giây kể từ kỷ nguyên, nhưng System.nanoTime()cung cấp cho bạn thời gian chính xác đến nano giây, liên quan đến một số điểm tùy ý.

Từ Tài liệu Java:

public static long nanoTime()

Trả về giá trị hiện tại của bộ định thời hệ thống có sẵn chính xác nhất, tính bằng nano giây.

Phương pháp này chỉ có thể được sử dụng để đo thời gian trôi qua và không liên quan đến bất kỳ khái niệm nào khác về thời gian hệ thống hoặc đồng hồ treo tường. Giá trị được trả về đại diện cho nano giây do một số thời gian gốc cố định nhưng tùy ý (có thể trong tương lai, vì vậy giá trị có thể âm). Phương pháp này cung cấp độ chính xác nano giây, nhưng không nhất thiết là độ chính xác nano giây. Không có đảm bảo nào được thực hiện về tần suất thay đổi giá trị. Sự khác biệt trong các cuộc gọi liên tiếp kéo dài hơn khoảng 292 năm (2 ⁶³ nano giây) sẽ không tính toán chính xác thời gian đã trôi qua do tràn số.

Ví dụ: để đo thời gian thực hiện một số mã:

long startTime = System.nanoTime();    
// ... the code being measured ...    
long estimatedTime = System.nanoTime() - startTime;

Xem thêm: JavaDoc System.nanoTime () và JavaDoc System.civerseTimeMillis () để biết thêm thông tin.

Vì không ai khác nhắc đến điều này

Không an toàn để so sánh kết quả của các System.nanoTime()cuộc gọi giữa các luồng khác nhau. Ngay cả khi các sự kiện của các luồng xảy ra theo thứ tự có thể dự đoán được, sự khác biệt về nano giây có thể là dương hoặc âm.

System.currentTimeMillis() là an toàn để sử dụng giữa các chủ đề.

Cập nhật bởi Arkadiy : Tôi đã quan sát thấy hành vi đúng hơn của System.currentTimeMillis()Windows 7 trong Oracle Java 8. Thời gian được trả về với độ chính xác 1 mili giây. Mã nguồn trong OpenJDK không thay đổi, vì vậy tôi không biết điều gì gây ra hành vi tốt hơn.

David Holmes của Sun đã đăng một bài viết trên blog cách đây vài năm, có một cái nhìn rất chi tiết về các API thời gian Java (đặc biệt System.currentTimeMillis()và System.nanoTime()), khi bạn muốn sử dụng chúng và cách chúng hoạt động nội bộ.

Bên trong Hotspot VM: Đồng hồ, Bộ hẹn giờ và Sự kiện Lập lịch - Phần I - Windows

Một khía cạnh rất thú vị của bộ đếm thời gian được Java sử dụng trên Windows cho các API có tham số chờ theo thời gian là độ phân giải của bộ hẹn giờ có thể thay đổi tùy thuộc vào những gì các lệnh gọi API khác có thể được thực hiện - toàn hệ thống (không chỉ trong quy trình cụ thể) . Ông cho thấy một ví dụ trong đó việc sử dụng Thread.sleep()sẽ gây ra thay đổi độ phân giải này.

System.nanoTime()không được hỗ trợ trong các JVM cũ. Nếu đó là một mối quan tâm, hãy gắn bó vớicurrentTimeMillis

Về độ chính xác, bạn gần như chính xác. Trên MỘT SỐ máy Windows, currentTimeMillis()có độ phân giải khoảng 10ms (không phải 50ms). Tôi không chắc tại sao, nhưng một số máy Windows cũng chính xác như máy Linux.

Tôi đã sử dụng GAGETimer trong quá khứ với thành công vừa phải.

Như những người khác đã nói, currentTimeMillis là thời gian đồng hồ, thay đổi do thời gian tiết kiệm ánh sáng ban ngày, người dùng thay đổi cài đặt thời gian, giây nhuận và đồng bộ hóa thời gian internet. Nếu ứng dụng của bạn phụ thuộc vào các giá trị thời gian trôi qua đơn điệu, bạn có thể thích nanoTime hơn.

Bạn có thể nghĩ rằng người chơi sẽ không quan tâm đến cài đặt thời gian trong khi chơi trò chơi và có lẽ bạn đã đúng. Nhưng đừng đánh giá thấp sự gián đoạn do đồng bộ hóa thời gian trên internet hoặc có lẽ người dùng máy tính để bàn từ xa. API nanoTime miễn dịch với loại gián đoạn này.

Nếu bạn muốn sử dụng thời gian của đồng hồ, nhưng tránh sự gián đoạn do đồng bộ hóa thời gian trên internet, bạn có thể xem xét một ứng dụng khách NTP như Meinberg, "điều chỉnh" tốc độ đồng hồ về 0, thay vì chỉ đặt lại đồng hồ theo định kỳ.

Tôi nói từ kinh nghiệm cá nhân. Trong một ứng dụng thời tiết mà tôi đã phát triển, tôi đã nhận được những đợt tăng tốc gió ngẫu nhiên. Phải mất một thời gian tôi mới nhận ra rằng cơ sở thời gian của mình đã bị gián đoạn do hành vi của thời gian trên PC điển hình. Tất cả các vấn đề của tôi biến mất khi tôi bắt đầu sử dụng nanoTime. Tính nhất quán (tính đơn điệu) quan trọng đối với ứng dụng của tôi hơn độ chính xác thô hoặc độ chính xác tuyệt đối.

Có, nếu độ chính xác như vậy là bắt buộc sử dụng System.nanoTime(), nhưng lưu ý rằng sau đó bạn đang yêu cầu JVM Java 5+.

Trên các hệ thống XP của tôi, tôi thấy thời gian hệ thống được báo cáo ít nhất 100 micro giây là 278 nano giây sử dụng mã sau:

private void test() {
    System.out.println("currentTimeMillis: "+System.currentTimeMillis());
    System.out.println("nanoTime         : "+System.nanoTime());
    System.out.println();

    testNano(false);                                                            // to sync with currentTimeMillis() timer tick
    for(int xa=0; xa<10; xa++) {
        testNano(true);
        }
    }

private void testNano(boolean shw) {
    long strMS=System.currentTimeMillis();
    long strNS=System.nanoTime();
    long curMS;
    while((curMS=System.currentTimeMillis()) == strMS) {
        if(shw) { System.out.println("Nano: "+(System.nanoTime()-strNS)); }
        }
    if(shw) { System.out.println("Nano: "+(System.nanoTime()-strNS)+", Milli: "+(curMS-strMS)); }
    }

Đối với đồ họa trò chơi và cập nhật vị trí trơn tru, sử dụng System.nanoTime()chứ không phải System.currentTimeMillis(). Tôi đã chuyển từ currentTimeMillis () sang nanoTime () trong một trò chơi và có một sự cải thiện lớn về mặt hình ảnh về độ mượt của chuyển động.

Mặc dù một phần nghìn giây có vẻ như nó đã chính xác, nhưng về mặt trực quan thì không. Các yếu tố nanoTime()có thể cải thiện bao gồm:

• định vị pixel chính xác dưới độ phân giải đồng hồ treo tường
• khả năng chống bí danh giữa các pixel, nếu bạn muốn
• Windows không chính xác đồng hồ treo tường
• jitter đồng hồ (không nhất quán khi đồng hồ treo tường thực sự tích tắc)

Như các câu trả lời khác cho thấy, nanoTime có chi phí hiệu năng nếu được gọi liên tục - tốt nhất là gọi nó chỉ một lần trên mỗi khung và sử dụng cùng một giá trị để tính toán toàn bộ khung.

Tôi đã có kinh nghiệm tốt với nanotime . Nó cung cấp thời gian đồng hồ treo tường là hai giây (giây kể từ epoch và nano giây trong giây đó), sử dụng thư viện JNI. Nó có sẵn với phần JNI được biên dịch sẵn cho cả Windows và Linux.

System.currentTimeMillis()không an toàn cho thời gian trôi qua vì phương pháp này nhạy cảm với sự thay đổi đồng hồ thời gian thực của hệ thống. Bạn nên sử dụng System.nanoTime. Vui lòng tham khảo trợ giúp về Hệ thống Java:

Về phương pháp nanoTime:

.. Phương pháp này cung cấp độ chính xác nano giây, nhưng không nhất thiết là độ phân giải nano giây (nghĩa là tần suất thay đổi giá trị) - không có đảm bảo nào được thực hiện ngoại trừ độ phân giải ít nhất bằng độ phân giải của currentTimeMillis () ..

Nếu bạn sử dụng System.currentTimeMillis()thời gian trôi qua của mình có thể âm (Quay lại <- cho tương lai)

một điều ở đây là sự không nhất quán của phương thức nanoTime. Nó không cung cấp các giá trị rất nhất quán cho cùng một đầu vào. , và do đó chính xác hơn trong giá trị của nó. do đó tôi sẽ đề nghị bạn sử dụng currentTimeMillis