0

I assume If a thread unsafe class's object creation is expensive and we would like to use that instance at different place for thread execution in multi threaded environment, we should use ThreadLocal. Because it is expensive and it is unnecessary to create new instances of those thread unsafe classes multiple times in a thread execution.

So SimpleDateFormat is example of this. Could you please tell me in what terms SimpleDateFormat is expensive? As well how would i know certain thread unsafe class's object creation would be expensive. So i must use ThreadLocal.

sdindiver
  • 491
  • 1
  • 5
  • 19
  • 1
    "_we should use `ThreadLocal`_" - ARGH! Why? What? Where did you get this strange idea? – Boris the Spider Apr 15 '18 at 17:01
  • Did you get your information regarding `SimpleDateFormat` from https://stackoverflow.com/questions/22098904/how-to-improve-performance-of-simpledateformat-wrapped-in-threadlocal? – luk2302 Apr 15 '18 at 17:03
  • @BorI have updated my question. I forgot to use thread unsafe class. SimpleDateFormat class is expensive. So rather than creating object at every place even in single thread execution, we could use thread local. So that it would be thread safe for each object and we don't have to create new objects everytime multiple times even in a single thread exution. https://stackoverflow.com/questions/817856/when-and-how-should-i-use-a-threadlocal-variable – sdindiver Apr 15 '18 at 17:06
  • no, No, NO. Use a [_pool_](https://stackoverflow.com/a/4921675/2071828). This is absolutely and positively **not** what `Threadlocal` is for. – Boris the Spider Apr 15 '18 at 17:08
  • You only know something is slow after you test wether or not it is slow. Or you find a valid post from a credible and reliable source that claims it is slow. – luk2302 Apr 15 '18 at 17:08
  • @luk2302 I would drop the second part - even if you find a valid post claiming that something is slow generally, you should cofirm whether it is slow in your use case. – Boris the Spider Apr 15 '18 at 17:09
  • @BoristheSpider Ah. You seem to be right. Because SimpleDateFormat class object creation is not dynamic. We could have it in object pool. But i have seen in so many websites as well as the link i have mentioned in above comment, people have SimpleDateFormat class object creation logic using ThreadLocal. I think in multi threaded environment for dynamic object creation and to use it in a lot of classes we could have it in ThreadLocal. – sdindiver Apr 15 '18 at 17:21
  • @BoristheSpider I have seen an example of this in spring security framework in which security context of user is put in threadlocal so that it can be called directly rather than passing in every method call. Am i right? – sdindiver Apr 15 '18 at 17:21
  • Exactly, that's different. That's binding a context to the thread - this context holds information about the current user. This is very different to your other use case - it has absolutely nothing whatsoever to do with creation expense. Also - I don't know where a thread pool came from... – Boris the Spider Apr 15 '18 at 17:23
  • So what about the link https://stackoverflow.com/questions/817856/when-and-how-should-i-use-a-threadlocal-variable – sdindiver Apr 15 '18 at 17:25
  • 2
    `SimpleDateFormat` is obsolete so the point is moot. [`DateTimeFormatter`](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) is now immutable and thread safe for this very reason. – Boris the Spider Apr 15 '18 at 17:57
  • Use a profiler. Find out how much object creation really costs. It's probably not worth optimizing. – Robert Apr 15 '18 at 18:14

0 Answers0