Является ли метод потокобезопасным, если он просто вызывает другой потокобезопасный метод в Java?

Question

Интересно, будет ли метод потокобезопасным, если он просто вызывает другой потокобезопасный метод?У меня есть такой пример.Как указано в документе, ConcurrentSkipListSet является потокобезопасным.

public class MessageHolder {

    private Set<String> processedIds;

    public MessageHolder() {
        this.processedIds = new ConcurrentSkipListSet<>();
    }

    public void add (String id) {
        processedIds.add(id);
    }

    public boolean contains (String id) {
        return processedIds.contains(id);
    }

    public void remove (String id) {
        processedIds.remove(id);
    }

}

Вы можете спросить, почему я не использую ConcurrentSkipListSet напрямую.Причина в том, что я хочу создать интерфейс для действий, выполняемых здесь, и этот пример будет похож на версию в памяти.

Answer 1

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

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

Для одного идентификаторы процесса должны быть окончательными, как упоминалось ранее.ВАШ КОД НЕ БУДЕТ БЕЗОПАСНЫ, пока ВЫ НЕ ДЕЛАЕТЕ ЭТО.Несмотря на то, что ConcurrentSkipListSet <> является потокобезопасным, это не помешает переназначению переменной processIds другим потоком.Кроме того, Java странная вещь, и ваше поле processIds должно быть помечено как final, чтобы гарантировать, что оно будет инициализировано до завершения работы конструктора.Я нашел этот пост, описывающий некоторые проблемы со строительством объектов в Java, для дальнейшего чтения. Конструктор синхронизации в Java .По сути, не помечайте ваши поля конструктора как синхронизированные, но если вы хотите гарантировать инициализацию переменной в конструкторе, что в этом случае вы делаете, то пометьте ваше поле как окончательное.

Чтобы ответить на ваш вопрос о том, является ли это потокобезопасным, единственным ответом будет то, что это зависит от ожидаемого использования клиента.Методы, которые вы предоставили, действительно поточнобезопасны для их предполагаемых целей, как написано, но клиент может использовать их и создавать условия гонки.Ваша интуиция о том, будет ли необходимо использовать синхронизированное ключевое слово на 100%, верна.Тем не менее, комментарии также намекают на то, что недопущение явного обеспечения безопасности этих методов в будущем может иметь некоторые серьезные последствия для удобства сопровождения и правильности вашего кода.

Клиент все еще может использовать предоставленный вами API небезопасным способом, что может привести к состоянию гонки, как упомянуто в одном из комментариев.Если вы предоставляете интерфейс клиенту, вы можете не заботиться об этом ... или вы можете позаботиться об этом и захотите предоставить клиенту механизм для множественного доступа к вашему классу с гарантированной безопасностью потоков.

В целом, я бы порекомендовал вам пометить ваши методы как синхронизированные по нескольким причинам. 1) Клиенту ясно, что он обращается к методам, которые являются потокобезопасными, что очень важно.Я легко могу представить ситуацию, когда клиент решает использовать блокировку, когда она не нужна в ущерб производительности.2) Кто-то может изменить ваши методы так, чтобы в будущем они содержали другую логику, которая требует ключевого слова synchronized (это не так уж и маловероятно, потому что вы, похоже, уже находитесь в многопоточном окружении).