Hashtable: как его использовать с 2/3 разными потоками?

На Android у меня есть одна хеш-таблица и два потока, которые могут получить к ней доступ. - доступ потока пользовательского интерфейса к нему с помощью containsKey, get и put - доступ к нему другого потока с помощью containsKey, get и put и итератора

Я знаю, что хэш-таблица является потокобезопасной, но уверен?

Одна вещь, которую я не понимаю: почему приложение не взрывается, если один поток не видит, что одно значение было удалено из хеш-таблицы, и поток выполняет итерацию по этому объекту?

Как мы можем определить хеш-таблицу потокобезопасной, если итератор не является?

EDIT: Но теперь я более конкретно расскажу вам о своей проблеме, потому что по-другому я не понимаю. Ниже сообщается код моего concurrentHashMap :

public ConcurrentHashMap<String,Result> Holder = new ConcurrentHashMap<String,Result>();

class Result
{
    public float goal = 0;
    public float min = 0;
    public float max = 0;
    public float seconds = 0;
    //lastaccess indicate the time of the last access of this Result
    public float lastaccess = 0;
    public boolean triggered = false;
}

Теперь один поток B повторяет каждые "x" секунд объект Result и для каждого ключа, хранящегося в Holder ConcurretHashMap .

Другой поток задает новый Результат для нового ключа или редактирует Результат для существующего.

  • Я хочу выполнить операцию обновления результата атомарным способом, но объект внутри хэш-карты меня пугает.

  • Поток UX удаляет все элементы из Holder каждые x секунд. Чтобы выполнить эту операцию, я сделал это следующим образом: я создал

    mlock объекта = новый объект();

в треде B

 syncrhonized(mlock)
    {
       //all the thread B function. 
       // Iterate on all of the Holder item
    }

в другом потоке C, когда ему нужно вызвать Holder.clear(), я сделал это следующим образом:

syncronized(mlock)
{
   Holder.clear();
}
  • Это правильный способ предотвратить итерацию потока B на держателе с несогласованными данными?

person aeroxr1    schedule 15.05.2015    source источник
comment
возможный дубликат Является ли java.util.Hashtable потокобезопасным?   -  person Chackle    schedule 15.05.2015
comment
@Chackle Я отредактировал свой вопрос, чтобы лучше объяснить мою проблему. Это так мало отличается от другого вопроса.   -  person aeroxr1    schedule 17.05.2015


Ответы (1)


Это потокобезопасно, но в сценариях с большим числом одновременных запросов рекомендуется использовать ConcurrentHashMap как вы можете видеть на официальном документация

person Claudio Redi    schedule 15.05.2015
comment
Спасибо ! Некоторые люди говорят, что и concurrentHashMap, и хеш-таблица небезопасны, потому что итераторы предназначены для использования только одним потоком за раз. Я боюсь, что если поток пользовательского интерфейса удалит элемент, другой поток не увидит этого небольшого изменения, и в моем приложении для Android возникнет какая-то проблема, потому что другой поток пытается получить доступ к несуществующему объекту в хеш-таблице. Я надеюсь быть ясным, мой английский не так хорош .. - person aeroxr1; 15.05.2015
comment
@aeroxr1: это правильно. Итератор небезопасен, так как представляет собой изображение содержимого в определенное время. Он не взорвется, но окончательно вы рискуете перебрать копию состояния данных, если тем временем элементы будут добавлены в другой поток. - person Claudio Redi; 15.05.2015
comment
И если поток не добавляет, а удаляет элемент, может быть очень проблематично, потому что мы обращаемся к нулевому объекту? или второй поток получит доступ к предыдущей копии объекта? Есть ли способ решить эту мою проблему? ConcurrenctHashMap имеет ту же проблему с итератором, верно? - person aeroxr1; 15.05.2015
comment
@aeroxr1: вам придется проанализировать, насколько важно получать онлайн-обновления хеш-таблицы. Возможно, в вашем сценарии можно пропустить обновление, выполненное во время итерации. Если это неприемлемо, допустимым вариантом может быть блокировка. - person Claudio Redi; 15.05.2015
comment
Я отредактировал свой первый пост, вставив часть своего кода и лучше объяснив свою проблему (или, по крайней мере, я так думаю) - person aeroxr1; 17.05.2015