Может ли это вызвать проблемы с сборкой мусора?

Question

Я написал маленький Linq, как DSL, поверх Google Collections

    public class IterableQuery {

   public static <T> Where<T> from(Iterable<T> originalCollection) {
      return  new Where<T>( Iterables.transform(originalCollection, IterableQuery.<T>SAME()));
   }

   private static <T> Function<T, T> SAME() {
      return new Function<T, T>(){
         public T apply(T arg0) {
            return arg0;
         }
      };
   }


   public static class SelectOrderBy<T>{

      private final Iterable<T> iterable;

      public SelectOrderBy(Iterable<T> iteable) {
         this.iterable = iteable;
      }

      public  SelectOrderBy<T> orderyBy( Comparator<T> sort ){
          Ordering.forComparator(sort).sort((List< ? extends T>) iterable);
          return new SelectOrderBy<T>( iterable);
      }

      public  <F> Iterable<F> select(  Function<? super T,? extends F> function){
         return Iterables.transform(iterable, function);
      }
      public  Iterable<T> selectEveryThing( ){
         return iterable;
      }
   }


   public static class Where<T>{

      private final Iterable<T> iterable;

      public Where(Iterable<T> iterable) {
         this.iterable = iterable;
      }

      public    SelectOrderBy<T> where(Predicate<T> predicate) {
         return  new SelectOrderBy<T>( Iterables.filter(iterable, predicate));
      }
   }

}

чтобы я мог делать коллекции запросов более кратким и понятным способом

 Iterable<? extends NewOrder > currentlyAssigned = 
         IterableQuery.
          from(orders).
          where(placedInLast10Days).
          orderBy(lastName). 
          select(orderToNewOrder);

Меня беспокоит, вызовет ли этот подход взрыв мини-объектов и вызовет некоторые проблемы со сборкой мусора (или любые другие проблемы)?

Answer 1

Я считаю, что Google Collections использует отложенное выполнение для большинства своих итераторов. Отложенное выполнение минимизирует количество создаваемых промежуточных объектов, поскольку устраняет большинство промежуточных / временных списков, которые могут быть созданы для каждого вызова (где, orderby и т. Д.).

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

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

Что касается ГХ, обрабатывающей много недолговечных объектов, то здесь проблем нет. Современный Java-сборщик мусора сильно оптимизирован, чтобы справиться с таким точным поведением.

Answer 2

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

Answer 3

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