Serait-ce causer des problèmes Garbage Collection

Question

J'ai écrit un peu Linq comme le DSL sur le dessus de 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)); 
     } 
    } 

} 

pour que je puisse faire des collections de la requête d'une manière lisible plus concise

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

Je suis préoccupé si cette approche provoquera une explosion de mini-objets et causera des problèmes de Garbage Collection (ou d'autres problèmes)?

Answer 1

Je pense que Google Collections utilise l'exécution différée pour la plupart de ses itérateurs. L'exécution différée réduirait au minimum le nombre d'objets intermédiaires créés car elle éliminerait la plupart des listes intermédiaires/temporaires qui pourraient être créées pour chaque appel (où, orderby, etc.).

Fondamentalement, chaque élément retourné par currentAssigned.iterator() n'est pas calculé tant que vous n'avez pas appelé iterator.next(). Jusque-là, votre iterable actuellement assigné est juste un ensemble d'opérations, rien de plus. Votre seule préoccupation concernant l'explosion de mini-objets si ces objets durent plus longtemps que la durée d'une opération d'un seul élément ... l'utilisation maximale de la mémoire pourrait devenir assez importante dans ce cas et vous pourriez potentiellement manquer de mémoire sur très grandes listes ou si vous étiez en train de convertir des objets (c'est-à-dire en appelant ToUpper() sur toutes les chaînes ou quelque chose). Ce ne serait le cas que si le résultat de where() était une autre liste, puis orderby() a créé une autre liste, et ainsi de suite.

En ce qui concerne la GC traitant de nombreux objets de courte durée, il n'y a pas de problème. Le garbage collector Java moderne fortement optimisé pour gérer ce comportement exact.

Answer 2

Je pense que cela dépend de la façon dont la transformation se comporte, si c'est comme un filtre paresseux, c'est-à-dire que vous n'attachez pas de référence à chaque résultat. alors son plus que l'objet OK compte le sage. Garbage sage sage, vous ne gardez aucune référence cachée, une fois que vous perdez la référence de racine le graphique entier devient inaccessible et est collecté. façon d'aller à l'homme c'est vraiment soigné.

Answer 3

Le garbage collector a un code spécial pour les objets de courte durée, et ils sont très très bon marché à utiliser. Fondamentalement, de temps en temps, tous les jeunes objets accessibles sont marqués et tous les autres objets sont récupérés d'un seul coup.