Поддерживает ли Java 8 поддержку кэшей для поставщиков?

Question

В библиотеке guava есть свой собственный Supplier, который не расширяет Java 8 Supplier. Также guava предоставляет кэш для поставщиков - Suppliers#memoize.

Есть ли что-то подобное, но для Java 8 поставщиков? не

Answer 1

Там нет встроенной функции Java для запоминания, хотя это не очень сложно реализовать, например, так:

public static <T> Supplier<T> memoize(Supplier<T> delegate) { 
    AtomicReference<T> value = new AtomicReference<>(); 
    return() -> { 
     T val = value.get(); 
     if (val == null) { 
      val = value.updateAndGet(cur -> cur == null ? 
        Objects.requireNonNull(delegate.get()) : cur); 
     } 
     return val; 
    }; 
} 

Обратите внимание, что существуют различные подходы к реализации. Вышеупомянутая реализация может вызвать делегата несколько раз, если замешанный поставщик запрашивал одновременно несколько раз из разных потоков. Иногда такая реализация предпочтительнее явной синхронизации с блокировкой. Если замок является предпочтительным, то DCL может быть использован:

public static <T> Supplier<T> memoizeLock(Supplier<T> delegate) { 
    AtomicReference<T> value = new AtomicReference<>(); 
    return() -> { 
     T val = value.get(); 
     if (val == null) { 
      synchronized(value) { 
       val = value.get(); 
       if (val == null) { 
        val = Objects.requireNonNull(delegate.get()); 
        value.set(val); 
       } 
      } 
     } 
     return val; 
    }; 
} 

Также обратите внимание, что @LouisWasserman правильно упоминается в комментариях, вы можете легко превратить JDK поставщика в Гуава поставщика, и наоборот, используя ссылки на метод:

java.util.function.Supplier<String> jdkSupplier =() -> "test"; 
com.google.common.base.Supplier<String> guavaSupplier = jdkSupplier::get; 
java.util.function.Supplier<String> jdkSupplierBack = guavaSupplier::get; 

Так что не стоит переходить между функциями Guava и JDK.

Answer 2

Самым простым решением было бы

public static <T> Supplier<T> memoize(Supplier<T> original) { 
    ConcurrentHashMap<Object, T> store=new ConcurrentHashMap<>(); 
    return()->store.computeIfAbsent("dummy", key->original.get()); 
} 

Однако самый простой не всегда является наиболее эффективным.

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

public static <T> Supplier<T> memoize1(Supplier<T> original) { 
    return new Supplier<T>() { 
     Supplier<T> delegate = this::firstTime; 
     boolean initialized; 
     public T get() { 
      return delegate.get(); 
     } 
     private synchronized T firstTime() { 
      if(!initialized) { 
       T value=original.get(); 
       delegate=() -> value; 
       initialized=true; 
      } 
      return delegate.get(); 
     } 
    }; 
} 

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

Внутри synchronized метода firstTime(), есть еще initialized флаг необходимо потому, что в случае одновременного доступа во время инициализации, несколько потоков могут ждать на входе методы перед делегатом был заменен. Следовательно, эти потоки должны обнаружить, что инициализация уже выполнена. Все последующие обращения будут читать новый поставщик делегатов и быстро получить значение.