У меня задача написать свой механизм блокировок Lock. И я нашел уже готовый самописный пример, упрощенной версии этого механизма:
public class Lock {
boolean isLocked = false;
Thread lockedBy = null;
int lockedCount = 0;
public synchronized void lock() throws InterruptedException{
Thread callingThread = Thread.currentThread();
while(isLocked && lockedBy != callingThread){
wait();
}
isLocked = true;
lockedCount++;
lockedBy = callingThread;
}
public synchronized void unlock(){
if(Thread.curentThread() == this.lockedBy) {
lockedCount--;
if(lockedCount == 0){
isLocked = false;
notify();
}
}
}
}
И меня ставят в ступор здесь несколько вещей:
1. Зачем нужен счетчик lockedCount какую проблему он решает?
2. Зачем нужен Thread callingThread = Thread.currentThread();? В чем идея этой проверки: lockedBy != callingThread? Какую проблему он решает?
Почему не сделать вот так, и успокоится:
public class Lock {
private boolean isLocked = false;
public synchronized void lock() throws InterruptedException {
while(isLocked) {
wait();
}
isLocked = true;
}
public synchronized void unlock(){
isLocked = false;
notify();
}
}
Зачем нужны эти дополнительные проверки что за проблему они решают?
Он позволяет потоку-владельцу блокировки блокировать ресурс многократно.
Для возможности сравнить текущий поток с тем, что владеет lock в данный момент.
Почему не сделать вот так, и успокоиться
Сделайте, не проблема. Вот только что делать, если текущий поток вызовет lock() повторно?
Как развивать веб-проекты в 2026 году: технологии, контент E-E-A-T и факторы доверия
Современные инструменты для криптотрейдинга: как технологии помогают принимать решения
Апостиль в Лос-Анджелесе без лишних нервов и бумажной волокиты
Основные этапы разработки сайта для стоматологической клиники