2010-05-15 2 views
2

java.util.Collections в настоящее время обеспечивает следующие вспомогательные методы для создания synchronized обертки для различных интерфейсов коллекции:Дать синхронизировано поточно-безопасность оболочку для NavigableMap

Аналогично, он также имеет 6 unmodifiedXXX перегрузок.

Впечатляющее упущение здесь - утилиты для NavigableMap<K,V>. Это правда, что это extends SortedMap, но так же SortedSet extends Set и Set extends Collection, и Collections имеют специальные методы утилиты для SortedSet и Set. Предположительно, NavigableMap - полезная абстракция, иначе она не была бы там в первую очередь, и все же для нее нет полезных методов.

Так вопросы:

  • Есть ли конкретная причина, почему Collections не предоставляет вспомогательные методы для NavigableMap?
  • Как вы писали свой собственный synchronized обертка для NavigableMap?
    • Взглянув на source code for OpenJDK version of Collections.java, кажется, предполагает, что это просто «механический» процесс
      • Верно ли, что в целом вы можете добавить synchronized поточно-safetiness особенность, как это?
      • Если это такой механический процесс, можно ли его автоматизировать? (Плагин Eclipse и т. Д.)
      • Требуется ли повторение этого кода или его можно избежать с помощью другого шаблона проектирования ООП?

ответ

4

Это был недосмотр. The fix is in progress.

Джош пишет:

«Они определенно принадлежат там Их отсутствие непреднамеренное
Мы должны положить их в как можно скорее...»

Согласен, хотя ни один из нас, инженеров, не ищет для написания (и тестирования) всех этих методов отталкивания ума. Дата публикации: 2006-08-21 00: 50: 41.0

Это требует времени.

Update: а вручную его реализации, вы можете рассмотреть возможность угнать java.util пакет, так как вы хотели бы расширить static class SynchronizedSortedMap<K, V> который объявлен пакет частных. Иначе это будет много копий кода. Вот зарезки боковых стволов:

package java.util; 

import java.util.Collections.SynchronizedSortedMap; 

public class NewCollections { 

    public static <K, V> NavigableMap<K, V> synchronizedNavigableMap(NavigableMap<K, V> m) { 
     return new SynchronizedNavigableMap<K, V>(m); 
    } 

    static class SynchronizedNavigableMap<K, V> extends SynchronizedSortedMap<K, V> implements NavigableMap<K, V> { 
     private final NavigableMap<K, V> sm; 

     SynchronizedNavigableMap(NavigableMap<K, V> m) { 
      super(m); 
      sm = m; 
     } 

     SynchronizedNavigableMap(NavigableMap<K, V> m, Object mutex) { 
      super(m, mutex); 
      sm = m; 
     } 

    } 
} 

Пусть IDE автоматическую генерацию невыполненных методы NavigableMap и кодировать их точно так же, как SynchronizedSortedMap делает. Вот один пример:

 @Override 
     public K ceilingKey(K key) { 
      synchronized (mutex) { return sm.ceilingKey(key); } 
     } 

Обратите внимание, что методы, которые возвращает к примеру Set вам нужно обернуть его в SynchronizedSet, а также. Опять же, см. Источники SynchronizedMap и SynchronizedSortedMap для получения информации :)

Я не ожидаю, что это будет (способно быть) механическим процессом, поскольку оно включает в себя множество факторов.

+0

Woot! Как авторитетно, так как это происходит от «почему?». Я не могу принять этот ответ прямо сейчас, так как отсутствует «как?». Не могли бы вы прокомментировать это? Это все еще большая часть моего вопроса. Насколько сложно писать и проверять эти «методы ошеломляющего перенаправления»? Не может быть полуавтоматизировано? И т. Д. – polygenelubricants

+0

Я бы просто скопировал 'static class SynchronizedMap' и' static class SynchronizedSortedMap' из источника 'Collections', добавил вашу собственную' SynchronizedNavigableMap', которая 'extends SynchronizedSortedMap' и украсит отсутствующие методы так же, как два скопированных класса делает. Это будет много кода, и уже поздно :) – BalusC

+0

это такой механический и «умопомрачительный» процесс! Казалось бы, это должно быть автоматизировано! – polygenelubricants

1

Есть ли конкретная причина, почему Collections не предоставляет вспомогательные методы для NavigableMap?

Я не могу придумать конкретную причину. Это либо

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

Но в любом случае причина не имеет значения.Утилита не существует, так что либо вы находите стороннюю библиотеку, либо реализуете ее самостоятельно.

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

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

Если это такой механический процесс, может ли он быть автоматизирован? (Плагин Eclipse и т. Д.)

Нет ... см. Выше.

Требуется ли повторение этого кода или его можно избежать с помощью другого шаблона проектирования ООП?

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

+0

только прояснить свое собственное понимание, хотя, это шаблон Decorator, что 'Collections' делает в отношении классов-оболочек ? например 'synchronizedSet' возвращает' Set', который «украшает» другой 'Set' с функцией безопасности, но сам по себе не выполняет какую-либо« Set-подобную »работу? – polygenelubricants

+0

@polygenelubricants Я бы сказал, что это правильно. –

2

Верно ли, что в целом вы можете добавить синхронизированную поточно-safetiness особенности как это?

Я считаю, что это правда. Определение безопасности потока (IMO),

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

Теперь, код будет гарантировать, что «Что-то» никогда не вызывается несколькими потоками, не так ли? Поэтому я считаю, что неблагоприятное поведение не может возникнуть из-за того, что его называют несколькими потоками; Он никогда не вызывается из нескольких потоков!

Возможно, это также идея EJB. Безгосударственные EJB никогда не вызываются более чем одним потоком (принудительным контейнером). Вот почему спецификация EJB может сказать: «Вам не нужно беспокоиться о безопасности потоков».

public class MakeSomethingThreadSafe implements Something { 
    private final Object lock = new Object(); 
    private final Something subject; 

    public MakeSomethingThreadSafe(Something subject){ 
     this.subject = subject; 
    } 

    public void someMethod(){ 
     synchronized(lock){ 
      subject.someMethod(); 
     } 
    } 
} 

Или я что-то упускаю?

Для того, чтобы после завершения:

Есть ли конкретная причина, почему Collections не предоставляет коммунальные метод NavigableMap?

Я согласен с Стивеном.

Как бы вы описали свою собственную синхронизированную упаковку для NavigableMap?

Как и мой пример кода ..

Верно ли, что в целом вы можете добавить синхронизированную поточно-safetiness особенности как это? Если это такой механический процесс , можно ли его автоматизировать? (Eclipse ),

Да, я думаю, что его можно легко автоматизировать.

  1. Реализовать интерфейс
  2. сделать 2 поля; Один для мьютекса, один для темы.
  3. Создайте конструктор, чтобы ввести объект.
  4. Сделайте каждый метод синхронизированным и передайте субъекту.

Является ли этот код повторение необходим, или его можно было бы избежать, различной ООП шаблона проектирования?

Нравится Set, Map и т. Д.? Мне не представляется возможным решить это «обычным» способом.

Смежные вопросы