На канале уже 2 видео есть в плейлисе Interview Spring можно пока их смотреть) th-cam.com/video/nNhMKhO34gE/w-d-xo.html th-cam.com/video/TwGtVidkhhs/w-d-xo.html Планирую 5 роликов снять
Вау, это очень мощно, круто, продолжай, ждем такое по Спрингу, хиберу и так далее. Это очень полезный контент P.S. уже увидел, что такие видео есть, но комент пусть будет)
почему в вопросе 125 2:01:10 говорится, что метод notify() и notifyAll() снимают блокировку, если они только оповещают другие потоки, которые ожидают на объекте синхронизации своей очереди?
Прошу прощения за опечатку ) Блокировка объекта будет освобождена только после того, как поток, который удерживает блокировку, завершит свой синхронизированный блок кода. На самом деле notify() и notifyAll() в Java не снимают блокировку объекта. Это распространенное заблуждение. Давайте разберемся, как они работают на самом деле. В Java, методы notify() и notifyAll() используются в многопоточном программировании в сочетании с методами wait(), notify() и notifyAll(), которые являются частью механизма ожидания и уведомления. Метод wait(): Когда поток вызывает wait() на объекте, он освобождает блокировку этого объекта и переходит в состояние ожидания до тех пор, пока другой поток не вызовет notify() или notifyAll() на том же объекте. Метод notify(): Когда поток вызывает notify(), он не освобождает блокировку этого объекта сразу. Вместо этого notify() сигнализирует одному из ожидающих потоков (если таковые есть), что он может продолжить работу. Однако поток, который вызвал notify(), продолжит удерживать блокировку до тех пор, пока не завершит синхронизированный блок (то есть покинет блок synchronized). Метод notifyAll(): Аналогично notify(), notifyAll() сигнализирует всем ожидающим потокам, что они могут продолжить выполнение, но поток, вызвавший notifyAll(), продолжит удерживать блокировку до выхода из синхронизированного блока. Таким образом, notify() и notifyAll() лишь сигнализируют другим потокам о возможности продолжить выполнение, но не освобождают блокировку сразу.
@@ReadWriteCode а зачем тогда в скобках под сигнатурой писать "тем же именем и тем же типом возвращаемого значения", если это не является сигнатурой. По-другому нормально нельзя было сформулировать?
Конечно, давайте более подробно. Существуют два типа исключений: проверяемые (checked) и непроверяемые (unchecked). Проверяемые исключения - это те, которые должны быть обработаны или объявлены в сигнатуре метода с использованием ключевого слова throws. Непроверяемые исключения могут быть обработаны, но это необязательно. Оператор catch предназначен для обработки исключений. Однако, когда речь идет о проверяемых исключениях, существует правило, что они должны быть либо обработаны в блоке catch, либо объявлены в сигнатуре метода с использованием throws. Теперь рассмотрим ваш вопрос и ответ: "Если нет возможности вызвать исключение в нашем коде, то мы не можем объявлять блок catch для обработки проверяемых исключений". Это означает, что если в вашем коде нет явного вызова (броска) проверяемого исключения, то компилятор не даст вам объявить блок catch для этого исключения. Например: public class Example { public static void main(String[] args) { // Нет явного вызова проверяемого исключения, // поэтому блок catch для него нельзя объявить. try { // some code } catch (CheckedException e) { // Ошибка компиляции e.printStackTrace(); } } } В данном примере CheckedException не может быть обработан в блоке catch, потому что в коде отсутствует явный вызов этого исключения. Ошибки времени компиляции будут возникать, если вы попытаетесь обработать проверяемые исключения в блоке catch, но не предоставите код, который может вызвать эти исключения в блоке try. Предположим, у нас есть класс, который объявляет метод, бросающий проверяемое исключение, и пытаемся его обработать в блоке catch. Если не будет вызова этого метода, компилятор выдаст ошибку. Вот пример: import java.io.IOException; public class Example { // Метод, бросающий проверяемое исключение public static void throwError() throws IOException { throw new IOException("This is a checked exception"); } public static void main(String[] args) { try { // Нет явного вызова throwError(), но мы пытаемся обработать его исключение // в блоке catch, что вызовет ошибку компиляции. catchCheckedException(); } catch (IOException e) { e.printStackTrace(); } } // Метод, пытающийся обработать проверяемое исключение private static void catchCheckedException() { // Ошибка компиляции, так как нет вызова throwError() в блоке try // и, следовательно, нет возможности бросить IOException. // Это нарушает правило компилятора. try { throwError(); // Ошибка компиляции } catch (IOException e) { e.printStackTrace(); } } } В данном примере метод catchCheckedException() пытается обработать проверяемое исключение (IOException), но нет явного вызова метода throwError(), который бросает это исключение. Компилятор Java выдаст ошибку компиляции, потому что он ожидает, что проверяемое исключение будет брошено в блоке try. Вы сами убедитесь если в среде разработки это попробуйте)
GitHub repository github.com/ReadAndWritecode/ReadAndWritecode/blob/master/src/interview/240-core-java-interview-questions-and-answers-all-parts.pdf
Как красиво у тебя всё оформлено. Спасибо тебе!
Такого ещё не было в ютюбе, чтобы прям столько вопросов и ответов в одном видео. Спасибо за труд!!.
А можно ещё такие видео снять про spring?
И вам спасибо за просмотр!).
Как раз следующая серия будет про вопросы и ответы по spring.
Материал огонь. Спасибо за твои труды. Теперь бы еще найти время все это просмотреть))
Болшое спасибо за проделанный труд. Вы очень помогает. Успехов вам.
Russian MF Do you speak it!
Однозначно ЛАЙК за труд!!! Ждём видос по Spring!!!!
На канале уже 2 видео есть в плейлисе Interview Spring можно пока их смотреть)
th-cam.com/video/nNhMKhO34gE/w-d-xo.html
th-cam.com/video/TwGtVidkhhs/w-d-xo.html
Планирую 5 роликов снять
Спасибо тебе огромное!!!
Прям очень всё круто!
Спасибо! Очень полезно!
Шедевр однозначно
Вау, это очень мощно, круто, продолжай, ждем такое по Спрингу, хиберу и так далее. Это очень полезный контент
P.S. уже увидел, что такие видео есть, но комент пусть будет)
Спасибо.
классное видео, запиши еще по спрингу что-то)))
по спрингу есть на канале 4 видео)
Спасибо!
почему в вопросе 125 2:01:10 говорится, что метод notify() и notifyAll() снимают блокировку, если они только оповещают другие потоки, которые ожидают на объекте синхронизации своей очереди?
Прошу прощения за опечатку )
Блокировка объекта будет освобождена только после того, как поток, который удерживает блокировку, завершит свой синхронизированный блок кода.
На самом деле notify() и notifyAll() в Java не снимают блокировку объекта. Это распространенное заблуждение. Давайте разберемся, как они работают на самом деле.
В Java, методы notify() и notifyAll() используются в многопоточном программировании в сочетании с методами wait(), notify() и notifyAll(), которые являются частью механизма ожидания и уведомления.
Метод wait():
Когда поток вызывает wait() на объекте, он освобождает блокировку этого объекта и переходит в состояние ожидания до тех пор, пока другой поток не вызовет notify() или notifyAll() на том же объекте.
Метод notify():
Когда поток вызывает notify(), он не освобождает блокировку этого объекта сразу. Вместо этого notify() сигнализирует одному из ожидающих потоков (если таковые есть), что он может продолжить работу. Однако поток, который вызвал notify(), продолжит удерживать блокировку до тех пор, пока не завершит синхронизированный блок (то есть покинет блок synchronized).
Метод notifyAll():
Аналогично notify(), notifyAll() сигнализирует всем ожидающим потокам, что они могут продолжить выполнение, но поток, вызвавший notifyAll(), продолжит удерживать блокировку до выхода из синхронизированного блока.
Таким образом, notify() и notifyAll() лишь сигнализируют другим потокам о возможности продолжить выполнение, но не освобождают блокировку сразу.
3 вопрос: разве тип возвращаемого значения входит в сигнатуру метода?
Спасибо за вопрос!.
В целом нет, но там для переопределения нужно было так сказать для представления).
@@ReadWriteCode а зачем тогда в скобках под сигнатурой писать "тем же именем и тем же типом возвращаемого значения", если это не является сигнатурой. По-другому нормально нельзя было сформулировать?
Поясните пожалуйста 74 вопрос "можем ли мы использовать оператор catch для проверяемых исключений?" и ответ на него, это 1:11:30
Конечно, давайте более подробно.
Существуют два типа исключений: проверяемые (checked) и непроверяемые (unchecked). Проверяемые исключения - это те, которые должны быть обработаны или объявлены в сигнатуре метода с использованием ключевого слова throws. Непроверяемые исключения могут быть обработаны, но это необязательно.
Оператор catch предназначен для обработки исключений. Однако, когда речь идет о проверяемых исключениях, существует правило, что они должны быть либо обработаны в блоке catch, либо объявлены в сигнатуре метода с использованием throws.
Теперь рассмотрим ваш вопрос и ответ:
"Если нет возможности вызвать исключение в нашем коде, то мы не можем объявлять блок catch для обработки проверяемых исключений".
Это означает, что если в вашем коде нет явного вызова (броска) проверяемого исключения, то компилятор не даст вам объявить блок catch для этого исключения. Например:
public class Example {
public static void main(String[] args) {
// Нет явного вызова проверяемого исключения,
// поэтому блок catch для него нельзя объявить.
try {
// some code
} catch (CheckedException e) { // Ошибка компиляции
e.printStackTrace();
}
}
}
В данном примере CheckedException не может быть обработан в блоке catch, потому что в коде отсутствует явный вызов этого исключения.
Ошибки времени компиляции будут возникать, если вы попытаетесь обработать проверяемые исключения в блоке catch, но не предоставите код, который может вызвать эти исключения в блоке try.
Предположим, у нас есть класс, который объявляет метод, бросающий проверяемое исключение, и пытаемся его обработать в блоке catch. Если не будет вызова этого метода, компилятор выдаст ошибку. Вот пример:
import java.io.IOException;
public class Example {
// Метод, бросающий проверяемое исключение
public static void throwError() throws IOException {
throw new IOException("This is a checked exception");
}
public static void main(String[] args) {
try {
// Нет явного вызова throwError(), но мы пытаемся обработать его исключение
// в блоке catch, что вызовет ошибку компиляции.
catchCheckedException();
} catch (IOException e) {
e.printStackTrace();
}
}
// Метод, пытающийся обработать проверяемое исключение
private static void catchCheckedException() {
// Ошибка компиляции, так как нет вызова throwError() в блоке try
// и, следовательно, нет возможности бросить IOException.
// Это нарушает правило компилятора.
try {
throwError(); // Ошибка компиляции
} catch (IOException e) {
e.printStackTrace();
}
}
}
В данном примере метод catchCheckedException() пытается обработать проверяемое исключение (IOException), но нет явного вызова метода throwError(), который бросает это исключение. Компилятор Java выдаст ошибку компиляции, потому что он ожидает, что проверяемое исключение будет брошено в блоке try.
Вы сами убедитесь если в среде разработки это попробуйте)
167 вопрос, Может ввести в заблуждение начинающих.
Начиная с Java 8 появились дополнительные возможности, желательно о них упомянуть.
Также хочу обратить внимание на 164 вопрос. Начиная с Java 8, в интерфейсах можно объявлять статические методы
Чтобы включить мозг в правильном направлении помогает, Спасибо
Однако есть устаревшая и неточная инфа
Спасибо за видео!
А можно получить ссылку на эту презентацию? Читать и находить быстрее нужные темы)
Спасибо за хороший отзыв!.
Ссылка в комментарии)
С++ не поддерживает многопоточность ?
Я C++ честно говоря, не знаю, но Google говорит, что начиная с C++11 поддерживает)
это можешь выложить в pdf?
Ссылка закреплена в самом первом комментарии)
@@ReadWriteCode Спасибо))
Армянин?
Ага)