Возможно ли, что производительность пострадает, если вы многократно приостанавливаете/возобновляете поток?

Question

Если да, просьба привести пример.

Например, когда мы возобновляем наш поток, время, необходимое для его получения и повторной инициализации текущего состояния, может занять столько времени, что нам лучше не прерывать поток вообще. Действительно ли это пример?

Answer 1

Короткие сообщения Да, почти все, что вы делаете с потоками, вводит некоторые накладные расходы, но в большинстве случаев, если вы решите использовать многопоточность, это потому, что эта стоимость легко оправдана. Остановка и возобновление потока подразумевает некоторые переключатели контекста, которые вводят только служебные данные для приложения.

Остановка и возобновление резьбы следует использовать осторожно, так как в этом Oracle Doc

Для других сред выполнения это может варьироваться, док просто о параллельности в Java, другие среды могут отличаться.

Некоторые цитаты из Oracle Documentation относительно опасностей и устаревания некоторых методов для возобновления и приостановки потоков. Это не столько проблемы с производительностью, сколько проблемы с концепцией и ошибки.

• Почему Thread.suspend и Thread.resume устарели?

Thread.suspend по своей сути является тупиковым. Если целевой поток удерживает блокировку на мониторе, защищающую критический системный ресурс, когда он приостановлен, ни один поток не может получить доступ к этому ресурсу до тех пор, пока целевой поток не будет возобновлен. Если поток, который возобновит целевой поток, попытается заблокировать этот монитор до вызова возобновления, результаты взаимоблокировки. Такие взаимоблокировки обычно проявляются как «замороженные» процессы.

• Почему Thread.stop не рекомендуется?

Потому что это по своей сути небезопасно. Остановка потока заставляет его разблокировать все мониторы, которые он заблокировал. (Мониторы разблокируются, поскольку исключение ThreadDeath распространяется на стек.) Если какой-либо из объектов, ранее защищенных этими мониторами, находился в противоречивом состоянии, другие потоки теперь могут просматривать эти объекты в несогласованном состоянии. Такие объекты, как говорят, повреждены. Когда потоки работают на поврежденных объектах, может возникнуть произвольное поведение. Такое поведение может быть тонким и трудным для обнаружения, или оно может быть выражено. В отличие от других исключенных исключений, ThreadDeath убивает потоки молча; таким образом, пользователь не предупреждает, что его программа может быть повреждена. Коррупция может проявиться в любое время после фактического ущерба, даже в часы или дни в будущем.