문제

여기서 비슷한 질문을했지만 내 만족에 대한 답이 없었습니다. 그래서 다시 질문을 다시 제출하십시오.

정기적으로 수행 해야하는 작업이 있습니다 (예 : 1 분 간격). Timertask & Timer를 사용하여 수면이있는 무한 루프가있는 새 스레드를 만드는 것과는 달리이를 수행 할 때 어떤 이점이 있습니까?

Timertask-를 사용한 코드 스 니펫-

TimerTask uploadCheckerTimerTask = new TimerTask(){

 public void run() {
  NewUploadServer.getInstance().checkAndUploadFiles();
 }
};

Timer uploadCheckerTimer = new Timer(true);
uploadCheckerTimer.scheduleAtFixedRate(uploadCheckerTimerTask, 0, 60 * 1000);

스레드와 수면을 사용한 코드 스 니펫-

Thread t = new Thread(){
 public void run() {
  while(true) {
   NewUploadServer.getInstance().checkAndUploadFiles();
   Thread.sleep(60 * 1000);
  }
 }
};
t.start();

논리의 실행이 간격 시간보다 더 많이 걸리면 특정주기를 놓치면 걱정할 필요가 없습니다.

이것에 대해 댓글을 달아주세요 ..

업데이트:
최근에 타이머 대 Thread.sleep ()의 또 다른 차이점을 발견했습니다. 현재 시스템 시간이 오전 11시라고 가정 해보십시오. 어떤 이유로 시스템 시간을 오전 10 시까 지 롤백하면 타이머는 오전 11시에 도달 할 때까지 작업을 실행 중지하는 반면 Thread.sleep () 메서드는 방해없이 작업을 계속 실행합니다. 이것은이 둘 사이에 무엇을 사용할 것인지 결정하는 데 중요한 의사 결정자가 될 수 있습니다.

도움이 되었습니까?

해결책

Timertask의 장점은 의도를 훨씬 더 잘 표현한다는 것입니다 (즉, 코드 가독성).

더 짧은 형태와 자신의 예로 작성할 수 있습니다.

Timer uploadCheckerTimer = new Timer(true);
uploadCheckerTimer.scheduleAtFixedRate(
    new TimerTask() {
      public void run() { NewUploadServer.getInstance().checkAndUploadFiles(); }
    }, 0, 60 * 1000);

다른 팁

Timer/Timertask는 작업의 실행 시간도 고려하므로 조금 더 정확합니다. 또한 멀티 스레딩 문제 (예 : 교착 상태를 피하는 등)를 더 잘 다루고 있습니다. 물론 일반적으로 일부 수제 솔루션 대신 잘 테스트 된 표준 코드를 사용하는 것이 좋습니다.

나는 왜 그런지 모르겠지만 내가 쓰고있는 프로그램은 타이머를 사용하는 것이었고 힙 크기가 끊임없이 증가하고있다.

스레드가 예외를 가져 와서 죽이면 문제가됩니다. 그러나 Timertask는 그것을 처리 할 것입니다. 이전 실행에서 실패에 관계없이 실행됩니다.

Java 스레드를 사용 하여이 작업을 관리하는 것에 대한 중요한 주장이 있습니다. sleep 방법. 당신은 사용 중입니다 while(true) 루프에 무기한 상태를 유지하고 잠을 자면서 실을 동면합니다. 만약 NewUploadServer.getInstance().checkAndUploadFiles(); 동기화 된 리소스를 차지합니다. 다른 스레드는 이러한 리소스에 액세스 할 수 없으며, 기아가 발생하여 전체 응용 프로그램 속도를 늦출 수 있습니다. 이러한 종류의 오류는 진단하기 어렵고 존재를 막는 것이 좋습니다.

다른 aproach는 당신에게 중요한 코드의 실행을 트리거합니다. NewUploadServer.getInstance().checkAndUploadFiles(); 전화로 run() 당신의 방법 TimerTask 한편 다른 스레드를 사용하여 자원을 사용하게하면서.

로부터 Timer 선적 서류 비치:

Java 5.0은 java.util.concurrent 패키지를 도입했으며 그 안에 동시 유틸리티 중 하나는 주어진 속도 또는 지연으로 작업을 반복적으로 실행하기위한 스레드 풀인 ScheduledThreadPooleExecutor입니다. 여러 서비스 스레드를 허용하고 다양한 시간 단위를 허용하며 서브 클래싱 타이머 스탁을 필요로하지 않기 때문에 타이머/타이머 스로크 조합을 효과적으로 대체 할 수 있습니다 (런 가능). 하나의 스레드로 ScheduledThreadPooleExecutor를 구성하면 타이머와 동일합니다.

그래서 선호합니다 ScheduledThreadExecutor 대신에 Timer:

  • Timer 모든 타이머 작업을 순차적으로 실행하는 데 사용되는 단일 배경 스레드를 사용합니다. 따라서 작업은 빠르게 완료해야합니다. 그렇지 않으면 후속 작업의 실행이 지연됩니다. 그러나 ScheduledThreadPoolExecutor 우리는 여러 스레드를 구성 할 수 있으며 ThreadFactory.
  • Timer 시스템 시계에 민감 할 수 있습니다. Object.wait(long) 방법. 하지만 ScheduledThreadPoolExecutor 아니다.
  • Timertask에 던져진 런타임 예외는 특정 스레드를 죽일 수 있으므로 타이머가 죽을 수 있습니다. ScheduledThreadPoolExecutor 다른 작업이 영향을받지 않도록합니다.
  • Timer 제공 cancel 메소드 타이머를 종료하고 예약 된 작업을 폐기하는 방법이지만 현재 실행중인 작업을 방해하지 않고 완료하도록합니다. 그러나 타이머가 데몬 스레드로 실행되면 취소 여부에 관계없이 모든 사용자 스레드가 실행 되 자마자 종료됩니다.

타이머 대 스레드

타이머는 사용합니다 Object.wait 그리고 그것은 다릅니다 Thread.sleep

  1. 대기 (wait) 스레드를 알 수 있습니다 (사용 notify) 다른 스레드에 의해서도 잠자는 스레드는 잠자는 것만 할 수 없으므로 중단 될 수 있습니다.
  2. 대기 (및 알림)는 모니터 객체에 동기화 된 블록에서 발생하는 반면 수면은 그렇지 않습니다.
  3. 수면은 자물쇠를 방출하지 않지만 대기 대기는 대기 대기에 대한 잠금 장치가 꺼집니다.

나는 당신의 문제를 이해한다고 생각합니다. 나는 매우 비슷한 것을보고 있습니다. 나는 반복되는 타이머를 가지고 있으며, 30 분마다, 그리고 며칠마다. 내가 읽은 내용과 내가 보는 의견에서, 모든 작업이 완료되지 않기 때문에 쓰레기 수집은 결코 실행되지 않을 것 같습니다. 타이머가 잠들 때 쓰레기 수집이 실행될 것이라고 생각하지만, 보지 못하고 문서에 따르면 그렇지 않습니다.

새 스레드 산란이 완성되고 쓰레기 수집이 허용된다고 생각합니다.

누군가 나를 잘못 증명하고, 내가 상속받은 것을 다시 쓰는 것은 고통이 될 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top