Переривання потоків,
Вирішив перевірити і закріпити матеріал лекції про переривання потоків, і зіткнувся з тим, що потік не переривається, тобто іноді переривається, але гарантії переривання немає. Наприклад за інформацією метод currentThread.interrupt () повинен переключитися private interruption змінної в стан true, але метод isInterupted () як і раніше повертає false, тобто по суті потік навіть не зрозумів що його спробували зупинити, хоча за матеріалом лекції перед викликом того ж методу sleep JVM перевіряє чи не намагався хтось цей потік зупинити, але sleep всерівно обробляється, і виходить нескінченний цикл. Може вся справа в тому, що інструкція interrupt () надсилається сплячому потоку, і коли він спить то все інструкції йому по боку, і по суті перервати потік можливо тільки слова виняток і обробивши його. Хотілося б пролити світло на дану ситуацію, адже погодьтеся це джерело майбутніх помилок. Спеціально написав код для implements Runnable, і extends Thread для перевірки різного роду об'єктів.
У потоку є public enum State (можна подивитися в Thread.java через IDEA клацнувши по будь-якому його властивості з затиснутим Ctrl) - стан.
Деякі методи (wait (), sleep (), join ()) виставляють стан або в
WAITING (якщо час очікування не задано, наприклад join ()), або
TIMED_WAITING (якщо задано час очікування, наприклад sleep (1000)).
У цих станах при виклику interrupt () очікування перерветься і буде згенеровано виняток InterruptedException без виставлення відповідного прапора (стан якого повертає isInterrupted ()).
P.S. Можливо, я не повністю прав.
Теж досліджую цю проблему цілий день. Поки що зрозумів такі моменти:
Якщо перед викликом методу interrupt () прибрати sleep (), то петля while не запуститься і дочірній потік завершиться. Значить Вайль прийшов прапор в положенні true і він не виконавши не однієї ітерації закрився і за ним відповідно закрився run. Якщо залишити в головному потоці Thread.sleep (500); поставивши затримку хоч 1 хоч навіть 0 млсек умова в while не спрацює. Виходить що наявність виклику методу сліп перед викликом методу ітерапт якимось чином змінює прапорець миттєво знову на фальш.
Другий момент.
Якщо взагалі прибрати цикл while і приспати дочірній потік на довго, то можна посередині сну розбудити його ітераптом з головного потоку і він благополучно завершиться:
Виходить що метод сліп під час свого виконання весь час моніторить прапорець ітераптед
По-моєму ні. Виклик tik.interrupt () призведе до генерування InterruptedException і ваш код потрапить в порожній обробник catch (). А Thread.sleep (60000) тут ні при чому, і якби замість нього був будь-якої математичний розрахунок - то він був би перерваний.
Все просто, на початку циклу перевіряється значення while, потім виконується все всередині циклу, на початку sleep, за ним переривання і вихід з блоку try, потім установка «прапорця» знову в положення false в блоці catch, і знову по новій. Первинну перевірку while проходить, а ось після перевірки, коли потік спить тоді переривання викликає нескінченний цикл. Те-є єдиний шанс коли isInterrupted () = true це коли команда дана або до блоку, або відразу після.
Інформація з Thinking in Java:
У секції catch виводиться повідомлення про переривання, разом із значенням, що повертається методом isInterrupted (). Коли інший потік викликає interrupt () для даного потоку, встановлюється прапор, який показує, що потік був перерваний. Однак цей прапор скидається при обробці виключення, тому всередині секції catch результатом завжди буде false. Прапор використовується в інших ситуаціях, де потік може досліджувати своє перерване стан осторонь від виключення.
Виходячи з вищевикладеного, метод sleep всередині потоку завжди повинен бути оточений блоком try catch (інший варіант компілятор пропустает) і блок catch завжди буде обнуляти параметр переривання, так-що в обробнику помилок варто ставити переривання потоку (або якісь інші корисні дії), в вруг випадках (наприклад затяжні тривалі вичіслетія, інше.) можна сподіватися на метод isInterrupted () і на те, що немає обробника помилок, який обнулить параметр переривання.
12583 читача / 2417 топіків