Как сделать ограничение по времени на время жизни потока в Java?

Question

[reus]

Как сделать ограничение по времени на время жизни потока в Java?

Я работаю с потоками в основном с через массив потоков + .join:

for (Advert adv : getAdverts()) {
			try {
				adv.join();
			} catch (InterruptedException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		}

Но иногда поток становится вечным и приложение замирает от .join
Можно ли как-то сделать ограничение на срок жизни потока (к примеру 60 сек.) и как это лучше делать?

Comments

[Толстый Лорри]

Лучше разобраться с причинами, которые делают его вечным =)
А так - как обычно с прерываниями потоков: заведите таймер внутри потока и проверяйте его каждый раз, перед тем, как начать выполнять новую порцию работы.

[reus]

Толстый Лорри: я использую selenium+phantomjs+proxy для парсинга. Бывает такое что прокси не отвечают и тред уходит в вечный сон

[Толстый Лорри]

reus: Неужели нигде тайм-ауты не настраиваются? По крайней мере у waiter'ы селениума умеют бросать эксепшны.

[reus]

Толстый Лорри: Написал просто тред менеджер, но я не уверен что это удачное решение:

public class ThreadsManager extends Thread {
	public ThreadsManager(ArrayList<Advert> results) {
		for (int i = 0; i < 120; i++) {
			for (Advert adv : results) {

				if (i == 119) {
					adv.interrupt();
					Main.log.warning(String.format("###############THREAD (advert.id=%s) WAS INTERRUPTED!", adv.id));
				}

				if (!adv.isAlive()) {
					break;
				}
			}
			try {
				Thread.sleep(1000);
			} catch (InterruptedException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		}
	}
}

[Толстый Лорри]

reus: Зачем вы его унаследовали от треда? Прерывать потоки извне - плохая практика (особенно, если они что-то куда-то пишут).
Покажите Advert с работой, которая внутри них крутится.

[reus]

Толстый Лорри: у Вас есть скайп/вк?

[Толстый Лорри]

reus: Мыло в профиле.

[Odissey Nemo]

Есть join с параметром - кол-вом миллисекунд до конца ожидания или же завершения нити, к которой исполняется join. Можно использовать его, чтобы не заснуть навсегда. И по выходу проверять, остановилась ли тестируемая нить, или же просто вышло заданное время ожидания нити. И далее реагировать в соответствии с логикой алгоритма.

[reus]

Толстый Лорри: А вот такой вопрос. Если использовать метод (не желательный) .close() в комбинации с методом освобождающим все ресурсы объекта (всем массивам/драйверам и тд. присваивать null ) это нормальный вариант или нет?

[Толстый Лорри]

reus: где это close() нежелательный? Наоборот, для него (AutoCloseable.close) даже целую конструкцию языка сделали - try-with-resources, чтобы он вызывался обязательно.
Учитывая, что вы не можете предсказать вызов сборщика мусора, то особого смысла null присваивать всему подряд нет, это лишь добавит сематнического шума в код. Вы НЕ освободите таким образом ресурсы объекта, вы просто лишитесь ссылки на них. Да, рано или поздно придет сборщик мусора, но такая оптимизация погоды не сделает.
Однако, присвоив ссылке на объект AutoCloseable значение null вы не освободите ресурсы, ибо они не управляются JVM (потому и нужен такой костыль со специальным интерфейсом, за который обязательно нужно дёрнуть).

Answer 1

[Hland]

Попробуй invokeAll