• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

thread save implementation of cached valueOf factory method?

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Any ideas if this can be not thread safe?
 
Sheriff
Posts: 21774
103
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moving to Threads and Synchronization.
 
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looks good to me.
 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An unintended side effect is possible according to me - (redundant) creation of several new FooClass(barCode) instances during simultaneous initial access.

Adam
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Ernest Friedman-Hill wrote:Looks good to me.



Aside from the potentially problematic memory leak inherent to caching objects in this manner.
Are you absolutely sure that working without a caching mechanism will devestate your application's performance, and it's not merely an attempt at premature optimization? Still, if a cache is warranted, this implementation might give you headaches further down the line, because it will never allow any of the cached objects to become eligible for garbage collection. Note that this depends entirely on the situation and it might never pose a problem in your specific situation, but it's definitely something to be wary of.
 
Michal Burak
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Adam Smolnik wrote:An unintended side effect is possible according to me - (redundant) creation of several new FooClass(barCode) instances during simultaneous initial access.

Adam



Yes. But those objects (the redundant copies) will be available for GC just after the method returns. I did not find a solution for that, any ideas?

Jelle Klap wrote:

Aside from the potentially (...)



Thanks for the info. Do you have any ideas how to solve my problem if I am determined to use a cache? I will access this method very frequently, and the pool of the objects can be 8-15 maximum.

Is there a way to implement such valueOf methods? I looked at the JDK sources and those are different case, since I have no idea what barCode can be.

EDIT2:
I am sure that I will have a maximum of about 15 objects I this cache. But the method will be called veery frequently. So I want to use it to optimalise memory usage so that I dont create lots of equal immutable objects.
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you'll only ever have that few distinct instances occupy the cache, I don't see any problems with this approach.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!