第 27 級。有關該級別主題的面試問題的答案

什麼是死鎖？

死鎖是兩個或多個執行緒被阻塞並互相等待的情況。死鎖也稱為死鎖。

死鎖是指兩個或多個佔用某些資源的進程試圖取得其他進程佔用的其他資源，但沒有一個進程能夠佔用它們所需的資源，從而釋放所佔用的資源的情況。

存在同步順序死鎖（透過順序賦值解決）；

物件之間的死鎖（不同的物件試圖存取相同的同步區塊）；

資源死鎖（當嘗試存取某些資源時，一次只有一個執行緒可以使用）。

您知道哪些策略可以防止死鎖發生？

當然，如果程式碼寫得沒有任何錯誤，那麼就不會有死鎖。但誰能保證他的程式碼寫得沒有錯誤呢？當然，測試有助於識別大部分錯誤，但正如我們之前所看到的，多執行緒程式碼中的錯誤並不容易診斷，即使在測試之後，您也無法確定是否存在死鎖情況。我們能以某種方式保護自己免受阻塞嗎？答案是肯定的。類似的技術也用在資料庫引擎中，它們經常需要從死鎖中恢復（與資料庫中的事務機制相關）。Lock套件中可用的介面及其實java.util.concurrent.locks作允許您嘗試使用該方法佔用與此類實例關聯的監視器tryLock（如果可以佔用監視器，則傳回 true）。

還有一種使用開放呼叫的策略，即調用同步區塊之外的其他物件的方法。

文章連結：Java 中的死鎖及其解決方法

使用方法時會發生死鎖嗎wait-notify？

我個人很難回答這個問題，但是在閱讀了網上關於這個主題的各種討論後，我們可以說：

可以透過合理使用synchronized、、volatile監視器（wait()、、）來避免死鎖，如果深入挖掘，則使用類別notify()：而不是普通集合 - 多執行緒選項（例如）；如果您需要更複雜的方式來同步線程 - 不同，.notifyAll()java.utils.concurrentConcurrentHashMapCyclicBarrierCountDownLatch

如果你正確使用wait- notify，那麼就不會發生死鎖。）））

這是連結：死鎖或死鎖。

哪個比較常用：notify或notifyAll？

The java.lang.Object.notify() wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object's monitor by calling one of the wait methods.

This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:

• By executing a synchronized instance method of that object.
• By executing the body of a synchronized statement that synchronizes on the object.
• For objects of type Class, by executing a synchronized static method of that class.

Only one thread at a time can own an object's monitor.

The java.lang.Object.notifyAll() wakes up all threads that are waiting on this object's monitor. A thread waits on an object's monitor by calling one of the wait methods.

The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object. The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object.

This method should only be called by a thread that is the owner of this object's monitor.

Это отрывки из documentации. Вопрос – то по большей части риторический, смотря Howое приложение, в зависимости от ситуации))) Я даже не знаю, How бы я ответил. Если у кого-то есть Howие-то догадки, то прошу в комментариях оставить, буду очень рад почитать.

Метод wait рекомендуется использовать с конструкциями if or while?

Здесь отвечу просто цитатой из сайта: Синхронизация потоков

По поводу вызова метода wait. Это уже из разряда чистой техники. Рекомендуется вызывать wait изнутри цикла while. Т.е., писать не

if (some condition){
    obj.wait()
}

..., а

while (some condition){
    obj.wait()
}

Зачем это надо. Дело в том, что notify может вызвать кто угодно. Просто по ошибке, от которой никто не застрахован. В том случае из опыта, о котором я рассказывал выше, мы взялись за переделку именно для того, чтобы избежать такой возможности. Просто спрятали an object, на котором происходит синхронизация. И доступ к нему имел только наш code. Это хорошая практика, но не всегда возможно, к сожалению. Так вот, если поток ждет выполнения некоторого условия – вариант с while надежнее. Если поток пустor по ошибке – он опять проверит condition и, если надо, будет ждать дальше.

Кроме того, не исключена возможность и простого выхода из ожидания без вызова notify. Я честно признаюсь, что не видел этого в спецификации виртуальной машины, хотя специально искал. Но некоторые «гуру» утверждают, что VM может выйти из состояния ожидания самопроизвольно. И более того, периодически это наблюдается. Если кто-нибудь даст ссылку на соответствующую спецификацию – буду благодарен!

What происходит после вызова метода notifyAll?

The java.lang.Object.notifyAll() wakes up all threads that are waiting on this object's monitor. A thread waits on an object's monitor by calling one of the wait methods.

Пробуждает все нити, которые ждали на этом мониторе.

Какие выгоды получает an object, если он immutable?

Нашел комментарий на: immutable-an objectы и многопоточность

Immutable an object — это an object, состояние которого после создания невозможно изменить. В случае Java это значит что все поля экземпляра у класс отмечены How final и являются примитивами or тоже immutable типами.

Пример:

public class ImmutablePoint {
    private final int x;
    private final int y;
    private final String description;

    public ImmutablePoint(int x, int y, String description) {
        this.x = x;
        this.y = y;
        this.description = description;
    }
}

После создания экземпляра ImmutablePoint его модификация невозможна.

Простейший пример immutable класса из JDK это String. Любые методы, которые вы вызовите на строке (например description.toLowerCase()) вернут новую строку, а не модифицируют исходную.

Пример mutable класс из JDK — Date. Например myDate.setHours(x) модифицирует сам экземпляр myDate!

Есть разница между immutable-an objectом (то есть, неизменяемым), и final-ссылкой.

Ключевое слово final для an objectных типов гарантирует неизменяемость лишь ссылки, но не самого an object. Например, если у вас есть final-link на ArrayList<T>, вы тем не менее можете добавлять в него новые элементы or изменять существующие.

В случае же immutable-an object an object после окончания конструктора не изменяется вообще. Одного лишь модификатора final для этого недостаточно, необходимо, чтобы все подan objectы были тоже неизменяемыми. Вы в принципе можете держать внутри ссылку на изменяемый an object, но обращаться с ним так, чтобы он не менялся.

Использование неизменяемых an objectов даёт много выгод. Например, о таком an objectе намного легче судить в ситуации, когда во многих частях программы есть link на него (для изменяемого an object, любая часть программы может вызвать мутирующую функцию в практически любой момент времени и из любого потока).

Но то, что для нас важно в контексте вопроса — неизменяемые an objectы не требуют синхронизации при многопоточном доступе. Вот собственно и вся рекомендация: используйте неизменяемые an objectы, и вам не придётся думать о том, что нужно, а что не нужно синхронизировать. Единственная возможная проблема — если вы внутри ещё не отработавшего конструктора публикуете ссылку на an object, через которую к нему может получить доступ кто-нибудь ещё, и увидеть an object в изменяющемся состоянии! (Это бывает не так уж и редко. Например, иногда программист хочет добавить an object в конструкторе в коллекцию всех an objectов данного типа.)

Следует различать действительно неизменяемые an objectы, и an objectы, имеющие лишь интерфейс «только для чтения». При чтении an object тем не менее может менять свою внутреннюю структуру (например, кэшировать самый свежий request данных). Такие an objectы не являются в строгом смысле неизменяемыми, и не могут быть использованы из разных потоков без предосторожностей. (Поэтому, если ваш an object включает другие an objectы, убедитесь, что documentация гарантирует их неизменяемость!)

Обратите внимание, что для полей неизменяемого an object вы практически обязаны использовать final! Дело в так называемой безопасной публикации. Смотрите. Инструкции в Java-программе могут быть переставлены How оптимизатором, так и процессором (у Java достаточно слабая модель памяти). Поэтому, если не предпринимать специальных действий, окончание работы конструктора и присвоение значений полям может быть переставлено (но невидимо в рамках текущего потока)! Использование final гарантирует, что такого не произойдёт.

В случае многопоточного программирования преимущества immutable классов очевидны: после создания an objectы можно передавать другим потокам и они всегда будут в актуальном состоянии. Т.е. вам не надо проверять не устарело ли состояние вашего экземпляра и не модифицировал ли его другой поток пока вы с ним работаете. Например, у вас есть метод bill(Date endDate), в нём вы наивно проверяете соответствие endDate Howим-то предварительным условиям и начинаете с ней работать. В этот момент другой поток может изменить endDate, например установит её глубоко в прошлое. Последствия могут быть самыми удивительными.

What такое «thread-safe»?

Опять же: What is thread Safe in java? [duplicate]

Thread safe means that a method or class instance can be used by multiple threads at the same time without any problems occuring.

Состояние потоко-безопасности подразумевает, что метод or класс может быть использован множеством нитей без проблем столкновения, то есть дедлоков.

Consider the following method:

private int myInt = 0;
public int AddOne()
{
    int tmp = myInt;
    tmp = tmp + 1;
    myInt = tmp;
    return tmp;
}

Now thread A and thread B both would like to execute AddOne(). but A starts first and reads the value of myInt (0) into tmp. Now for some reason the scheduler decides to halt thread A and defer execution to thread B. Thread B now also reads the value of myInt (still 0) into it's own variable tmp. Thread B finishes the entire method, so in the end myInt = 1. And 1 is returned. Now it's Thread A's turn again. Thread A continues. And adds 1 to tmp (tmp was 0 for thread A). And then saves this value in myInt. myInt is again 1.

Здесь и нить А и нить B хотят выполнить AddOne (). но А начинается первой и считывает meaning myInt (0) в TMP. Теперь по некоторым причинам планировщик решает остановить поток А и отложить выполнение нити B. Поток В настоящее время также считывает meaning myInt (0) в его собственной переменной TMP. Нить B завершает весь метод так, что в конце концов myInt = 1. И 1 возвращается. Поток А продолжается. И добавляет 1 к TMP (TMP 0 для нити A). А затем сохраняет это meaning в myInt. myInt снова 1.

So in this case the method AddOne was called two times, but because the method was not implemented in a thread safe way the value of myInt is not 2, as expected, but 1 because the second thread read the variable myInt before the first thread finished updating it.

Так что в этом случае метод AddOne был вызван два раза, но так How этот метод не был реализован в потоке безопасным способом величина myInt не 2, How ожидалось, а 1, потому что второй поток чтения переменной myInt закончился перед первой нитью до его обновления.

Creating thread safe methods is very hard in non trivial cases. And there are quite a few techniques. In Java you can mark a method as synchronized, this means that only one thread can execute that method at a given time. The other threads wait in line. This makes a method thread safe, but if there is a lot of work to be done in a method, then this wastes a lot of time. Another technique is to 'mark only a small part of a method as synchronized' by creating a lock or semaphore, and locking this small part (usually called the critical section). There are even some methods that are implemented as lockless thread safe, which means that they are built in such a way that multiple threads can race through them at the same time without ever causing problems, this can be the case when a method only executes one atomic call. Atomic calls are calls that can't be interrupted and can only be done by one thread at a time.

Creation потоко-безопасных методов очень трудно. В Java вы можете пометить метод How синхронизированный, это будет означать, что только один поток может выполнить этот метод в данный момент времени. Другие нити, будут ждать в очереди. Это делает метод потоко-безопасным, но если много работы предстоит сделать в методе, то на это будет уходить много времени. Другой метод заключается в разметке лишь малой части метода, How синхронизированного 'путем создания локов(locks) or семафоров, и запирании этой небольшой части (обычно называемый критический раздел (critical section)). Есть даже некоторые методы, которые реализуются How беззамочные потокобезопасные (lockless thread safe), это означает, что они построены таким образом, что несколько потоков могут проходить через них в одно время и никогда не вызывают проблем, это может быть в случае, когда метод выполняет только один атомарный вызов. Атомарные вызовы это вызовы, которые не могут быть прерваны, и может быть реализованы только одним потоком.

What такое "happens-before"?

Есть статья на википедии, она не конкретно про "happens-before", но все – таки.

А так-то:
«Выполняется прежде» (англ. happens before) — отношение строгого частичного порядка (арефлексивное, антисимметричное, транзитивное), введённое между атомарными командами (++ и -- не атомарны!), придуманное Лесли Лэмпортом и не означающее «физически прежде». Оно значит, что вторая команда будет «в курсе» изменений, проведённых первой.

Модель памяти Java

В частности, одно выполняется прежде другого для таких операций (список не исчерпывающий):

• Синхронизация и мониторы:
• Захват монитора (начало synchronized, метод lock) и всё, что после него в том же потоке.
• Возврат монитора (конец synchronized, метод unlock) и всё, что перед ним в том же потоке.
• Таким образом, оптимизатор может заносить строки в синхроблок, но не наружу.
• Возврат монитора и последующий захват другим потоком.
• Запись и чтение:
• Любые зависимости по данным (то есть запись в любую переменную и последующее чтение её же) в одном потоке.
• Всё, что в том же потоке перед записью в volatile-переменную, и сама запись.
• volatile-чтение и всё, что после него в том же потоке.
• Запись в volatile-переменную и последующее считывание её же.[4][2] Таким образом, volatile-запись делает с памятью то же, что возврат монитора, а чтение — то же, что захват.[5] А значит: если один поток записал в volatile-переменную, а второй обнаружил это, всё, что предшествует записи, выполняется раньше всего, что идёт после чтения; см. иллюстрацию.
• Для an objectных переменных (например, volatile List x;) столь сильные гарантии выполняются для ссылки на an object, но не для его содержимого.
• Обслуживание an object:
• Статическая инициализация и любые действия с любыми экземплярами an objectов.
• Запись в final-поля в конструкторе[6] и всё, что после конструктора. Как исключение из всеобщей транзитивности, это соотношение happens-before не соединяется транзитивно с другими правилами и поэтому может вызвать межпоточную гонку.[7]
• Любая работа с an objectом и finalize().
• Обслуживание потока:
• Запуск потока и любой code в потоке.
• Зануление переменных, относящихся к потоку, и любой code в потоке.
• Код в потоке и join(); code в потоке и isAlive() == false.
• interrupt() потока и обнаружение факта останова.

What такое JMM?

Java Memory Model

Вот link: Chapter 17. Threads and Locks

И вот выдержка из нее:

A memory model describes, given a program and an execution trace of that program, whether the execution trace is a legal execution of the program. The Java programming language memory model works by examining each read in an execution trace and checking that the write observed by that read is valid according to certain rules.

Я понял на своем уровне что это набор правил:

Правило № 1: однопоточные программы исполняются псевдопоследовательно. Это значит: в реальности процессор может выполнять несколько операций за такт, заодно изменив их порядок, однако все зависимости по данным остаются, так что поведение не отличается от последовательного. Правило № 2: нет невесть откуда взявшихся значений. Чтение любой переменной (кроме не-volatile long и double, для которых это правило может не выполняться) выдаст либо meaning по умолчанию (ноль), либо что-то, записанное туда другой командой.br /> И правило № 3: остальные события выполняются по порядку, если связаны отношением строгого частичного порядка «выполняется прежде» (англ. happens before).

Какое исключение вылетит, если вызвать wait не в блоке synchronized?

Вот link: Ответы на вопросы на собеседование Multithreading (часть 2)

Основная причина вызова wait и notify из статического блока or метода в том, что Java API обязательно требует этого. Если вы вызовете их не из синхронизированного блока, ваш code выбросит IllegalMonitorStateException. Более хитрая причина в том, чтобы избежать состояния гонки между вызовами wait и notify.