#concurrency #java
class A {
int a;
int b;

void m1() {
a++;
b++;
}

void m2() {
System.out.println(b);
System.out.println(a);
}
}

// пример вывода: b=1 a=0

Методы m1 и m2 запускаются в разных потоках, одновременно, один раз каждый

Сколько вариантов может напечатать thread2? #concurrency

Какие варианты вывода могут быть? (y,x)
(похожая задача была тут - https://t.me/java_interview_tasks/26)
(Методы thread1 и thread2 запускаются в разных потоках, одновременно, один раз каждый)

public class Test {

int x;
volatile int y;

public void thread1() {
x = 1;
y = 1;
}

public void thread2() {
System.out.println(y);
System.out.println(x);
}
}

Известно, что x++ над volitile полем x не атомарен (https://t.me/java_interview_tasks/94), давайте посмотрим насколько серьезными могут быть потери данных в случае гонки:

Вопрос:
Что может напечатать код?

(Варианты ответов в следующем опросе, в каждом варианте перечислены списки значений которые могут быть выведены на экран)

#concurrency

Какие значения может напечатать код (thread1 и thread2 запускаются одновременно в разных потоках)?
#jmm #concurrency #java #java_interview_tasks

Ответ на вопрос VolatileVsFinal (https://t.me/java_interview_tasks/140) :

Тут речь идет об одном из самых интересных разрешенных сценариев JMM. Это тот факт, что volatile поле не имеет final семантики.
Это означает, что если мы публикуем ссылку объекта под гонкой, то мы можем увидеть дефолтное значение для volatile поля
Поэтому в данном случае 0 вполне можно получить.

Этот эффект можно увидеть на некоторых платформах, например AArch64:
RESULT SAMPLES FREQ
-1 1,428,517,070 91.74%
0 7,105 <0.01%
42 128,534,641 8.25%

#concurrency корректно ли будет работать код в многопоточной среде?

Ответ про код с ConcurrencyStorage:
Тут concurrency проблема, связанная с тем,
что ссылка на storage заново присваивается в методе fillStorage()
и нет гарантий что другой поток, который вызовет метод getValue() увидит данные,
обновленные в fillStorage();
Что бы эту проблему исправить, можно, например, сделать поле storage volatile:
private volatile ConcurrentMap<String, String> storage = new ConcurrentHashMap<>();

🔍 Ответ на задачу о ConcurrentHashMap и атомарности

Одно из часто обсуждаемых свойств ConcurrentHashMap — это ее потокобезопасность в отношении методов put и get. ConcurrentHashMap гарантирует атомарность операций put и get, что значит, что каждое из этих действий выполняется полностью или не выполняется вовсе, и они могут безопасно выполняться одновременно из разных потоков.

⚡️Однако важно помнить, что эта гарантия распространяется только на сами операции put и get, но не на атомарность действий по отношению к вложенным объектам. В нашем случае, если мы извлекаем список из мапы и затем изменяем его, эти изменения не защищены от состояния гонки. Как было показано в предыдущей задаче, два потока могут создать и модифицировать один и тот же список, приводя к непредсказуемым результатам.

⚡️⚡️Поэтому при работе с ConcurrentHashMap, когда объекты, хранящиеся в мапе, также должны быть потокобезопасными, следует дополнительно обеспечивать синхронизацию либо использовать другие потокобезопасные структуры данных.

👉 Чтобы решить проблему, можно воспользоваться несколькими подходами. Вот некоторые из них:

/*
Solves the race with putIfAbsent
*/

void addCorrect(String key, String val) {
            List<String> list = map.get(key);
            if (list == null) {
                list = Collections.synchronizedList(new ArrayList<>());
                List<String> exist = map.putIfAbsent(key, list);
                if (exist != null) {
                    list = exist;
                }
            }
            list.add(val);
        }

/*
Solves the race with computeIfAbsent.
*/

 void addCorrect8(String key, String val) {
            List<String> list = map.computeIfAbsent(key,
                    k -> Collections.synchronizedList(new ArrayList<>()));
            list.add(val);
        }

🎓 Понравилась тема про потокобезопасность в Java? Ставьте лайк, подписывайтесь на канал и делитесь своими мыслями в комментариях!

#ConcurrentHashMap #Java #Concurrency #Atomicity #java_interview_tasks

🔍 Ответ на задачу про checkThenReact и состояние гонки:

В этом примере метода checkThenReact() описывается ситуация типичной проблемы конкурентного программирования, известной как "состояние гонки". Суть проблемы заключается в том, что несколько потоков (в данном случае actor1() и actor2()) могут одновременно проверить и изменить общее состояние, здесь представляемое переменной flag.

Возможные решения для устранения состояния гонки:
Синхронизация:

Заключите операцию проверки и изменения flag в блок синхронизации:

private synchronized boolean checkThenReact() {
    if (flag) {
        flag = false;
        return true;
    } else {
        return false;
    }
}

Использование AtomicBoolean:

Замена boolean на AtomicBoolean и использование атомарных операций. Например:

private final AtomicBoolean flag = new AtomicBoolean(true);

private boolean checkThenReact() {
    return flag.compareAndSet(true, false);
}

Эти подходы помогут устранить логическую проблему и гарантировать, что только один поток сможет изменить состояние flag в одно и то же время.

🎓Если вам интересны темы конкурентности и потокобезопасности, ставьте лайк, подписывайтесь и оставляйте комментарии с вашими вопросами и переживаниями!

#Concurrency #RaceCondition #Synchronization #AtomicOperations #java_interview_tasks