🔍 Ответ на вопрос про пропавший эксепшен:
Привет, друзья! Сегодня обсудим скрытую проблему с логированием исключений, которая часто возникает в многопоточной среде.
На первый взгляд все кажется довольно обычным: мы отправляем задачу на выполнение, которая вызывает метод logString с null значением. Это должно вызвать NullPointerException.
❓ Где же исключение? Вы могли заметить, что исключение не будет напечатано в логи, даже если оно происходит. Почему?
🔎 Объяснение:
Исключения в Java, возникающие в потоке, обрабатываются контекстом этого потока.
В случае использования ExecutorService.submit(...), если задача выбрасывает исключение, оно остается незамеченным, потому что submit возвращает Future, который просто тихо удаляет это исключение.
Если вы не вызываете методы get() у Future и не обрабатываете возможное исключение, вы его просто не увидите.
💡 Как это исправить? Чтобы исключение стало видимым, можно сделать следующее:
public static void main(String[] args) {
ExecutorService executorService = Executors.newSingleThreadExecutor();
Future<?> future = executorService.submit(() -> logString(null));
try {
future.get(); // Обрабатываем возможное исключение
} catch (InterruptedException | ExecutionException e) {
e.printStackTrace(); // Выводим исключение в логи
} finally {
executorService.shutdown();
}
}
📌 В этом изменении future.get() либо вернёт результат, либо выбросит ExecutionException, если что-то пошло не так, позволяя вам логировать и обрабатывать ситуацию корректно.
👨💻 Вывод: Будьте внимательны при работе с многопоточностью. Убедитесь, что вы корректно обрабатываете возможные исключения, особенно при использовании ExecutorService.
➖➖➖➖➖
🎓 Надеюсь, это было полезно! Оставьте свои вопросы и комментарии ниже. 👇
Подписывайтесь, чтобы не пропустить важные советы и приемы! 🔥
#java #многопоточность #исключения #программирование #лучшиепрактики
Привет, друзья! Сегодня обсудим скрытую проблему с логированием исключений, которая часто возникает в многопоточной среде.
На первый взгляд все кажется довольно обычным: мы отправляем задачу на выполнение, которая вызывает метод logString с null значением. Это должно вызвать NullPointerException.
❓ Где же исключение? Вы могли заметить, что исключение не будет напечатано в логи, даже если оно происходит. Почему?
🔎 Объяснение:
Исключения в Java, возникающие в потоке, обрабатываются контекстом этого потока.
В случае использования ExecutorService.submit(...), если задача выбрасывает исключение, оно остается незамеченным, потому что submit возвращает Future, который просто тихо удаляет это исключение.
Если вы не вызываете методы get() у Future и не обрабатываете возможное исключение, вы его просто не увидите.
💡 Как это исправить? Чтобы исключение стало видимым, можно сделать следующее:
public static void main(String[] args) {
ExecutorService executorService = Executors.newSingleThreadExecutor();
Future<?> future = executorService.submit(() -> logString(null));
try {
future.get(); // Обрабатываем возможное исключение
} catch (InterruptedException | ExecutionException e) {
e.printStackTrace(); // Выводим исключение в логи
} finally {
executorService.shutdown();
}
}
📌 В этом изменении future.get() либо вернёт результат, либо выбросит ExecutionException, если что-то пошло не так, позволяя вам логировать и обрабатывать ситуацию корректно.
👨💻 Вывод: Будьте внимательны при работе с многопоточностью. Убедитесь, что вы корректно обрабатываете возможные исключения, особенно при использовании ExecutorService.
➖➖➖➖➖
🎓 Надеюсь, это было полезно! Оставьте свои вопросы и комментарии ниже. 👇
Подписывайтесь, чтобы не пропустить важные советы и приемы! 🔥
#java #многопоточность #исключения #программирование #лучшиепрактики
🔥15❤4👍4🙏1
🔍 Ответ на вопрос про volatile и массивы в Java:
📌 Многие разработчики могут ошибочно полагать, что при объявлении массива volatile все его элементы также будут обладать свойствами volatile. Однако это не так!
Пример выше как раз демонстрирует эту особенность.
🔎 Объяснение:
volatile int[] arr делает переменную arr ссылкой volatile. Это означает, что любые изменения ссылки на массив будут видны другим потокам.
Однако элементы массива не наследуют volatile-свойство. Таким образом, arr[0] и arr[1] не имеют гарантий видимости друг для друга.
➖➖➖➖➖
Ставьте лайк , если нашли это полезным и задавайте свои вопросы и комментарии ниже для получения дополнительных знаний! 🚀
#java #многопоточность #volatile #программирование
📌 Многие разработчики могут ошибочно полагать, что при объявлении массива volatile все его элементы также будут обладать свойствами volatile. Однако это не так!
Пример выше как раз демонстрирует эту особенность.
🔎 Объяснение:
volatile int[] arr делает переменную arr ссылкой volatile. Это означает, что любые изменения ссылки на массив будут видны другим потокам.
Однако элементы массива не наследуют volatile-свойство. Таким образом, arr[0] и arr[1] не имеют гарантий видимости друг для друга.
➖➖➖➖➖
Ставьте лайк , если нашли это полезным и задавайте свои вопросы и комментарии ниже для получения дополнительных знаний! 🚀
#java #многопоточность #volatile #программирование
Telegram
Java Interview Tasks
Какие значения могут напечататься? (thread1 и thread2 запускаются одновременно в разных потоках)
🔥10👍4❤3👎1👏1🙏1🐳1
🔍 Ответ на задачу про работу с многопоточностью в Java
Давайте разберёмся, что происходит при запуске данного кода! 🔍
Объяснение:
thread::start — запускает новый поток, который выполняет переданное лямбда-выражение. В отдельном потоке выводятся значения от 0 до 4. Поток выполняет метод run, и будет выполняться параллельно с основным потоком.
thread::run — здесь метод run вызывается в основном потоке так, как если это был обычный метод, а не в отдельном потоке. Это означает, что в основном потоке без создания нового потока пойдет выполнение того же самого кода ещё раз, так как метод run просто выполняется в потоке, из которого он был вызван.
Следовательно, программа завершится успешным выполнением, и будут выведены две последовательности от 0 до 4. Таким образом, правильный ответ — Код скомпилируется и выполнится, но "thread::run()" будет выполняться в основном потоке.
Эта ситуация — прекрасный пример, демонстрирующий разницу между методами start() и run() в многопоточности. 🌟
Не забудьте поставить лайк, подписаться на канал и оставлять комментарии с вашими идеями и вопросами! 💬👉
#Java #Многопоточность #Concurrency #java_interview_tasks
Давайте разберёмся, что происходит при запуске данного кода! 🔍
public class ThreadTest {
public static void main(String[] args) {
Thread thread = new Thread(() -> {
for (int i = 0; i < 5; i++) {
System.out.println(Thread.currentThread().getName() + " - " + i);
}
});
thread.start();
thread.run();
}
}
Объяснение:
thread::start — запускает новый поток, который выполняет переданное лямбда-выражение. В отдельном потоке выводятся значения от 0 до 4. Поток выполняет метод run, и будет выполняться параллельно с основным потоком.
thread::run — здесь метод run вызывается в основном потоке так, как если это был обычный метод, а не в отдельном потоке. Это означает, что в основном потоке без создания нового потока пойдет выполнение того же самого кода ещё раз, так как метод run просто выполняется в потоке, из которого он был вызван.
Следовательно, программа завершится успешным выполнением, и будут выведены две последовательности от 0 до 4. Таким образом, правильный ответ — Код скомпилируется и выполнится, но "thread::run()" будет выполняться в основном потоке.
Эта ситуация — прекрасный пример, демонстрирующий разницу между методами start() и run() в многопоточности. 🌟
Не забудьте поставить лайк, подписаться на канал и оставлять комментарии с вашими идеями и вопросами! 💬👉
#Java #Многопоточность #Concurrency #java_interview_tasks
🔥8👍6❤3