Вычисления карты: вычисления значения заранее

Я подозреваю, что вы идете по неправильному пути, сосредотачиваясь на приоритетах потоков. Обычно данные, которые хранит кэш, дорого вычисляются из-за ввода-вывода (данные о выходе из памяти) по сравнению с привязкой к ЦП (логические вычисления). Если вы предварительно загружаете, чтобы угадать будущие действия пользователя, такие как просмотр непрочитанных электронных писем, то это указывает мне на то, что ваша работа, вероятно, связана с вводом-выводом. Это означает, что до тех пор, пока не происходит голодание потоков (что планировщики запрещёвывают),Игра в игры с приоритетом потоков не обеспечит значительного повышения производительности.

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

Один из распространенных способов согласования такого типа ситуации - иметь карту, значения которой являются объектами FutureTask. Итак, взяв в качестве примера некоторый код, который я написал с моего веб-сервера, основная идея заключается в том, что для данного параметра мы видим, существует ли уже FutureTask (что означает, что расчет с этим параметром уже запланирован), и если да, то ждем. В этом примере мы в противном случае планируем поиск, но это можно было бы сделать в другом месте с помощью отдельного вызова, если бы это было желательно:

  private final ConcurrentMap<WordLookupJob, Future<CharSequence>> cache = ...

  private Future<CharSequence> getOrScheduleLookup(final WordLookupJob word) {
    Future<CharSequence> f = cache.get(word);
    if (f == null) {
      Callable<CharSequence> ex = new Callable<CharSequence>() {
        public CharSequence call() throws Exception {
          return doCalculation(word);
        }
      };
      Future<CharSequence> ft = executor.submit(ex);
      f = cache.putIfAbsent(word, ft);
      if (f != null) {
        // somebody slipped in with the same word -- cancel the
        // lookup we've just started and return the previous one
        ft.cancel(true);
      } else {
        f = ft;
      }
    }
    return f;
  }

Что касается приоритетов потоков: интересно, достигнет ли это того, что вы думаете? Я не совсем понимаю вашу точку зрения о повышении приоритета поиска над ожидающим потоком: если поток ожидает, то он ждет, независимо от относительных приоритетов других потоков ... (Возможно, вы захотите взглянуть на некоторые Я написал статьи о приоритетах потоков и планировании потоков , но, короче говоря, я не уверен, что изменение приоритета обязательно принесет вам то, что вы ожидаете .)

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

AtomicInteger highPriorityCount = new AtomicInteger();

void highPriorityTask() {
  highPriorityCount.incrementAndGet();
  try {
    highPriorityImpl();
  } finally {
    highPriorityCount.decrementAndGet();  
  }
}

void lowPriorityTask() {
  if (highPriorityCount.get() == 0) {
    lowPriorityImpl();
  }
}

В вашем случае оба метода Impl () будут вызывать get () на карте вычислений, highPriorityImpl () в том же потоке и lowPriorityImpl () в другом потоке.

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