스레드 중지: 공식 버전

"안녕하세요, 아미고! Ellie의 취소 아이디어가 훌륭했음을 인정해야 합니다."

"네."

"실제로 비슷한 것이 Thread 클래스에 존재합니다. 변수만 isCancel 이라고 하지 않습니다. isInterrupt 라고 합니다 . 그리고 스레드를 중지하는 데 사용되는 메서드는 cancel() 이 아닙니다 . interrupt() 입니다 ."

"정말?"

"예. 확인해보세요."

class Clock implements Runnable
{
public void run()
{
Thread current = Thread.currentThread();

while (!current.isInterrupted())
{
Thread.sleep(1000);
System.out.println("Tick");
}
}
}

public static void main(String[] args)
{
Clock clock = new Clock();
Thread clockThread = new Thread(clock);
clockThread.start();

Thread.sleep(10000);
clockThread.interrupt();
}

또한 run 메서드 에서 무한 루프로 사람들이 즐겨 사용하는 sleep 메서드는 isInterrupt 변수를 자동으로 확인합니다 . 스레드가 sleep 메서드를 호출하면 메서드는 먼저 해당 스레드에 대해 isInterrupt가 참인지 확인합니다. 그것이 사실이라면 메소드는 잠들지 않을 것입니다. 대신 InterruptedException 예외가 발생합니다.

"왜 예외를 던질까요? 루프에 isCancel() 대신 isInterrupted()를 넣는 것이 낫지 않을까요?"

" 첫째 , run 메소드에 항상 루프가 있는 것은 아닙니다. 이 메소드는 단순히 다른 메소드에 대한 수십 번의 호출로 구성될 수 있습니다. 그런 다음 각 메소드 호출 전에 isInterrupted 검사를 추가해야 합니다."

" 둘째 , 다양한 작업이 많이 포함된 일부 메서드는 실행하는 데 매우 오랜 시간이 걸릴 수 있습니다."

" 셋째 , 예외 발생은 isInterrupted 검사를 대체하지 않습니다. 단지 편리한 추가 기능일 뿐입니다. 발생된 예외를 사용하면 호출 스택을 run 메서드 자체 로 빠르게 되돌려 놓을 수 있습니다. "

" 넷째 , 수면 방법이 많이 사용됩니다. 밝혀진 바와 같이, 이 유용한 방법은 그다지 도움이 되지 않는 암묵적 확인으로 향상됩니다. 마치 아무도 특별히 확인을 추가하지 않은 것처럼 보이지만, 거기에 있습니다. 이것은 매우 가치가 있습니다. 다른 사람의 코드를 사용하고 있고 수표를 직접 추가할 수 없습니다."

" 다섯째 , 추가 검사는 성능을 저하시키지 않습니다. sleep 메서드를 호출한다는 것은 스레드가 아무 작업도 수행하지 않아야 함을 의미하므로(수면 제외) 추가 작업으로 인해 아무도 귀찮게 하지 않습니다."

"그것들은 심각한 주장입니다."

"그리고 마지막으로 다음이 있습니다. run 메서드는 다른 사람의 코드, 즉 액세스할 수 없는 코드(소스 코드 및/또는 코드를 변경할 수 있는 권한)를 호출할 수 있습니다. isInterrupted 검사가 없을 수 있으며 다음을 사용할 수 있습니다. " try ... catch (Exception e) "는 모든 예외를 catch합니다."

아무도 스레드가 중지될 것이라고 보장할 수 없습니다. 스레드만 자체적으로 중지할 수 있습니다.