Thread.sleep chờ đợi hơn dự kiến

Các mã sau đây:Thread.sleep chờ đợi hơn dự kiến

long msBefore = System.currentTimeMillis(); 
//Thread.currentThread().setPriority(Thread.MAX_PRIORITY); 
try 
{Thread.sleep(200); 
} catch (InterruptedException e){} 
System.out.println("Time: " + (System.currentTimeMillis() - msBefore));

in:

Time: 578 
Time: 594 
Time: 625 
Time: 640 
Time: 641 
Time: 609 
Time: 625 
Time: 625 
Time: 610 
Time: 609 
Time: 625 
Time: 625 
Time: 422 
Time: 625 
Time: 594 
Time: 609 
Time: 625 
Time: 594 
Time: 594 
Time: 625

đâu vấn đề ??

Nguồn

2011-05-23 Muhammad Hewedy

Mặc dù bạn phải tuân theo tính chính xác của hệ thống, nó phải gần gũi hơn với điều này. Trên hệ thống Windows và Linux của tôi, nó hiếm khi dài hơn 2 ms so với dự kiến. Bạn có hệ điều hành nào? –

Xin chào Mohammed. Như những người khác đã chỉ ra, điều này sẽ phụ thuộc vào độ chính xác của hệ thống của bạn (ngay cả các yếu tố môi trường như nhiệt độ có thể đá vào). Chỉ vì tò mò, vấn đề thực tế bạn đang cố giải quyết bằng mã này là gì? Tùy thuộc vào câu trả lời của bạn, ai đó ở đây có thể giúp bạn một cách tốt hơn để làm điều đó (ví dụ: TimerTaskExecutor sẽ chính xác hơn nhiều khi in nhịp tim thông thường). Hãy đảm bảo bạn nêu câu hỏi theo một chủ đề khác. Chúc mừng. –

Tôi đã chạy nó vài lần sau đó, và nó là một mở rộng tuyệt vời chính xác ngay bây giờ. Cảm ơn tất cả đã giúp đỡ. –

Không có vấn đề gì ở đây. Từ javadoc:

tùy thuộc vào độ chính xác của hệ thống và bộ lập lịch.

Thông thường, thiết kế kém phải dựa vào khoảng thời gian ngủ vì nó có thể khác nhau trên các hệ thống khác nhau và triển khai JVM. Sử dụng wait() và thông báo() thay vào đó, hoặc tốt hơn - sử dụng gói java.util.concurrent.

Nguồn

2011-05-23 10:10:12

Tôi có yêu cầu gửi n tin nhắn mỗi giây, tôi nghĩ việc chờ/thông báo không phù hợp, đúng không? –

Sử dụng lớp Timer để thực hiện điều đó. –

chờ/thông báo sử dụng cùng một bộ tính giờ như chế độ ngủ. Nó chỉ là chính xác. –

Tôi có yêu cầu gửi n tin nhắn mỗi giây, tôi nghĩ việc chờ/thông báo không phù hợp, đúng không?

Nếu bạn có yêu cầu về thời gian khó, thì bạn sẽ cần sử dụng triển khai real-time Java. Các triển khai Java chính thống của SE và ME không phù hợp với các ứng dụng thời gian thực cứng.

Có nhiều thủ thuật khác nhau mà bạn có thể sử dụng để đáp ứng các yêu cầu đó "hầu hết thời gian" ... nhưng nếu ứng dụng/hệ thống của bạn bị quá tải, bạn phải chịu trách nhiệm bắt đầu thiếu thông báo bắt buộc.

Sự cố thực sự không phải là độ chính xác của bộ hẹn giờ, nhưng thực tế là công cụ lên lịch không thực tế sẽ không (và không thể) để lên lịch chạy ngay khi bộ hẹn giờ hết hạn.

Nguồn

2011-05-23 10:19:10

Cảm ơn bạn đã liên kết và thông tin. –

Bạn không tính đến thời gian xử lý.

try { 
     long processingStart = System.currentTimeMillis(); 

     long processingFinish = System.currentTimeMillis(); 
     long processTime = 600 - (processingFinish - processingStart); 
     Thread.sleep(processTime); 

    } catch (InterruptedException ex) { 

    }

Nguồn

2012-02-26 06:07:02 javaExpert

Nếu bạn thực sự cần tốc độ tin nhắn cố định, hãy thực hiện điều gì đó giống như khóa xoay. Nó sẽ tiêu thụ lõi CPU đơn, nhưng giúp bạn gần gũi.

long nextTime = System.currentTimeMillis() + interval; 
while (keepRunning) { 
    while (nextTime - System.currentTimeMillis() > 0) 
     ; 
    sendMessage(); 
    nextTime += interval; 
}

Nguồn

2012-06-18 20:37:29

Thread.sleep chờ đợi hơn dự kiến ​​

Trả lời

Các vấn đề liên quan

Thread.sleep chờ đợi hơn dự kiến