1

In one of my classes say SimpleDate, I need some objects like DateFormat which may be used a lot of time from various instances. For this reason, I would like to make them static.

However, I would also want that these objects should be garbage collected if needed when we do not have any instances of the SimpleDate object left. A static declaration would not allow that to happen.

So basically I want something like

private weakstatic DateFormat df = DateFormat.getInstance();

This DateFormat instance should be eligible for garbage collection if no objects of the declaring class exist anymore. Also, it should be reinitialised whenever any new instance of the declaring class is created. This way we can avoid recreation of objects used repeatedly but also free the memory when they are not needed anymore.

I know it should be possible using WeakReferences. However, I am not able to figure out a way to do it.

Edit: DateFormat may be a wrong candidate here since it is not thread safe. But it should be as thread safe as declaring them static.

The idea is that we often make variables static that are used across instances. And these variables linger for ever till the application process dies. So if you just touch a class, its static variables remain in memory forever.

Adwiv
  • 1,283
  • 9
  • 15
  • 2
    This is a bad idea for several reasons, not least of all because `SimpleDateFormat` isn't thread-safe so cannot be safely shared between threads without some form of synchronisation. Secondly, that's not how weak references work and thirdly, have you got data to prove that your instances of `DateFormat` are causing a memory problem? – biziclop Feb 11 '15 at 10:46
  • 2
    Adding to what biziclop wrote about thread (non) safety, please look at `ThreadLocal` if you are using `SImpleDateFormat`. – vikingsteve Feb 11 '15 at 10:49
  • Thanks. Maybe DateFormat is a wrong candidate here then. But it should be as safe as declaring them static. The idea is that we often make variables static that are used across instances. And these variables linger for ever till the application process dies. – Adwiv Feb 11 '15 at 10:50
  • @vikingsteve ThreadLocal looks like something I am looking for. Will investigate and let you know. – Adwiv Feb 11 '15 at 10:56
  • @vikingsteve ThreadLocal very GC unfriendly in some circumstances (app servers, for example). – Nikolay Feb 11 '15 at 10:58
  • There still is a fundamental flaw with this idea. Weak references only make sense if something else may or may not hold a strong reference to the same thing. So in a way, weak references only work well for "secondary reference", not as the authoritative source for an object. Imagine how that `DateFormat` would be used: some method somewhere will grab the shared instance, call one method on it, then throw it away. It won't hold a strong reference for a longer time period so at that point there's nothing that stops GC of collecting it. – biziclop Feb 11 '15 at 10:58
  • @Nikolay thanks for that heads-up, can you suggest something better? – vikingsteve Feb 11 '15 at 11:09
  • @vikingsteve From what I read, ThreadLocal is better than using static for non-thread safe classes. However, they would still hold up resources accessed on the main thread for ever. – Adwiv Feb 11 '15 at 11:13
  • Are you really have memory issues with this objects? Classloader leaks (in app-servers) or ThreadLocal object leaks (thread renew in servlet containers, Jetty for ex.) are really worst cases. I suggest use cache+factory for this objects. – Nikolay Feb 11 '15 at 11:21
  • 2
    This entire issue sounds like a massive exercise in pointless micro-optimization. What objects are so expensive to keep around that you're going to notice the overhead at all? – chrylis -cautiouslyoptimistic- Feb 11 '15 at 11:28
  • @chrylis for me it is more of a theoretical exercise of why this is not possible. why am I forced to have variables that either die with the instance or live for ever :-) – Adwiv Feb 11 '15 at 11:39
  • possible duplicate of [Are static fields open for garbage collection?](http://stackoverflow.com/questions/453023/are-static-fields-open-for-garbage-collection) – Joe Feb 11 '15 at 12:23

1 Answers1

0

I would have a look at the answer on this question, which describes how to use ThreadLocal to add thread-safety to classes which are not inherently thread-safe, such as SimpleDateFormat.

Date Conversion with ThreadLocal

Since you only need one instance of DateFormat - per format (which you may or may not have several of) and per thread - I doubt you actually need to worry about garbage collection or using WeakReference.

Nikolay has raised a concern about memory when using ThreadLocal, please see his link in the comments below and see if this applies to your use-case or not.

Community
  • 1
  • 1
vikingsteve
  • 38,481
  • 23
  • 112
  • 156
  • Not performance, but memory. Look at this https://stackoverflow.com/questions/17968803/threadlocal-memory-leak In few words: if you control your threads, use ThreadLocal, if not -- avoid it et al. – Nikolay Feb 11 '15 at 11:35