java - Objectpool vs. immutable Objects -

say working simple class , object creation not heavy:

class simple {   public final int data1;   public final float data2;   ... } 

you have continuously put simple-objects queue:

queue.add(new simple(123,123f,...)); 

is faster work object-pool , change simple-class modifiable class? hope not.

generally, no isn't faster. if configure jvm use "throughput" gc, better performance not attempting recycle objects. worth considering object pools if either "memory constrained" or if gc pauses problematic. (the amortized cost of garbage collecting object tends towards 0 proportion of garbage non-garbage increases, if objects "die young", per generational hypothesis.)

in fact:

• if application multi-threaded, object pool may concurrency bottleneck, and

• mutation of "effectively immutable" objects may require additional overhead and/or additional synchronization.

---

if object creation rate "about 20 objects per second", using object pool unlikely make significant difference performance, if produces improvement (which doubt).

do math.

• if object size simple n bytes, , allocating m per second, can estimate number of bytes per second allocated.

• if "young space" y mbytes, take t seconds trigger gc based on allocation rate.

• if "young space" gc takes on average g ms space of size y, can estimate upper bound on time hypothetically saved ... assuming object pool had 0 associated overheads.

• the actual saving less, because "zero overheads" assumption unrealistic.

in fact time take "young space" collection doesn't depend on size. depends on amount of non-garbage needs retained. (less non-garbage retained better!) can make gc overhead hard estimate. however, if have coded application without object pool, can measure average "young space" collection time application typical workload, , plug calculations above.