Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Regarding correctness, by switching YEAR_INFO_CACHE to static, you've introduced a minor memory leak. There are a few ways to tell if your static references matter in practice, e.g. do a back-of-the-envelope approximation of how large the cache will grow based on what you know about the data; profile the heap during/after a load test of your application; etc.</p> <p>You're caching such small objects that you probably can cache a lot of them without a problem. Still, if you find that the cache needs to be bounded, then you have a few options, such as an LRU cache, a cache based on soft references instead of direct (strong) references, etc. But again, I emphasize that for your particular situation, implementing either of these <a href="https://stackoverflow.com/questions/1115825/using-softreference-for-static-data-to-prevent-memory-shortage-in-java">might be a waste of time</a>.</p> <p>To explain the theoretical problem with static references, I'll refer to other posts, rather than reproducing them here:<br/> 1. <a href="https://stackoverflow.com/questions/453023/are-static-fields-open-for-garbage-collection">Are static fields open for garbage collection?</a><br/> 2. <a href="https://stackoverflow.com/questions/641462/can-using-too-many-static-variables-cause-a-memory-leak-in-java">Can using too many static variables cause a memory leak in Java?</a></p> <p>Also regarding correctness, the code is thread safe not because references are final, but rather because the YearInfo values created by multiple threads for some cache position must be equal, so it doesn't matter which one ends up in the cache.</p> <p>Regarding design, all of the YearInfo related stuff in the original Joda code is private, so the YearInfo details including caching are well encapsulated. This is a good thing.</p> <p>Regarding performance, the best thing to do is profile your code and see what's using a significant amount of CPU. For profiling, you want to see whether the time spent in this code matters in the context of your entire application. Run your app under load, and check if this particular part of the code matters. If you don't see a performance problem in this code even without the YearInfo cache, then it's probably not a good use of time to work on / worry about that cache. Here is some information about how to do the check:<br/> 1. <a href="https://stackoverflow.com/questions/3035601/performance-profiler-for-a-java-application">Performance profiler for a java application</a><br/> 2. <a href="https://stackoverflow.com/questions/2952519/how-to-find-cpu-intensive-class-in-java">How to find CPU-intensive class in Java?</a><br/> That said, the converse is true -- if what you've got is working, then leave it as is!</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload