1

Is it good, if the java code is oversaturated with final variables? I think about performance. As far as I know, the final variables are thread safe. So, for each initialization on final variable jvm must synchronize its value among all threads. If I use final variables in every case where I want the variable to be non-modifiable, will it strike performance?

I expect and afraid that final variables will DECREASE the performance.

Dumas45
  • 501
  • 1
  • 10
  • 20
  • You might want to take at look at [this](http://stackoverflow.com/questions/2412124/are-final-static-variables-thread-safe-in-java). In short: the reference, which is final, is thread-safe, the object itself is not. – Turing85 May 29 '15 at 08:22
  • I knew that final variables are thread safe! Thats why I expect and afraid DECREASE of performance – Dumas45 May 29 '15 at 08:26

3 Answers3

7

I see your point. Generally speaking, a class with final fields is thread-safe just because you cannot write code which modifies those fields directly in runtime. So, no any other thread can modify an instance of such immutable class unexpectedly. Now, about the cost. There is no specific java bytecode to read/write final fields. Moreover, you can change any final field via Reflection, JNI calls, generated bytecodes (besides the "normal" constructor route). That means that the final fields are not effectively final, they seem to be just a compilation time restriction, a kind of syntax sugar. But, there is one specific aspect of final fields which MAY affect performance, because JMM defines specific semantic for them (usually specialty costs, doesn't it? :) ): http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5 It defines synthetic synchronize action "Freeze action" for constructors which contain final fields. That action is a part of "Freeze action - Read of reference to the created object" HB edge which really guarantees that all threads see correctly initialized final fields. But we see that in the real life there is no any significant difference between frozen and non-frozen constructors: http://shipilev.net/blog/2014/all-fields-are-final/

So, the bottom line is that final fields cost almost the same as non-final ones. Local final variables is a pure syntax sugar and cost nothing over non-final locals.

And finally, if you develop a high-performance/low-latency application, don't use immutable objects (don't allocate memory all the time) in the main path of it, use mutable objects (with buffers, pools, etc) instead, because typically even an empty constructor costs about 30ns + minor GC also isn't for free + cache locality is worst in case of intensive memory (re)allocation...

AnatolyG
  • 1,557
  • 8
  • 14
2

There is no performence reason behind final variables. You can gain performance by using immutable objects, becaus in that case java can avoid GC to run on those objects. Even if a field is final, you only say that you don't move the few bytes of the pointer to this object, it has no performance impact, because you still can modify the fields of this object. The only way to improve performance (by reducing the GC overhead) is by using immutable objects where possible. But you need to be reasonable, not to force everything to be immutabale at the cost of reducing code readability.

Krzysztof Cichocki
  • 6,294
  • 1
  • 16
  • 32
  • 1
    Conversely, I can increase performance using only mutable objects – Dumas45 May 29 '15 at 08:32
  • 1
    Yes, it is almost like question, is drinking water from a glass the best approach, or should I drink it from the tap? In theory if java can avoid GC runs, then you will have more CPU for your app, which should improve performance. But there is always but... some special cases... some JVM designs, some GC designs... it all can vary – Krzysztof Cichocki May 29 '15 at 08:35
0

there is no performance issues with final variables.

If you want to use variables in multi thread environment rather than using final variables use Volatile variables.

Volatile variables are thread-safe. volatile keyword in Java guarantees that value of volatile variable will always be read from main memory and not from Thread's local cache.

Anil Reddy Yarragonda
  • 747
  • 5
  • 19
  • I kind of disagree with this - Volatile variables are thread-safe. ?? Yes your next lines explain use of volatile. But we still need Synchronization. – Ouney May 29 '15 at 09:51
  • We are using synchronization only for methods. we cannot use same for variables. if multiple threads are accessing on variables then data will be corrupted. To overcome this problem Volatile variables are introduced . – Anil Reddy Yarragonda May 29 '15 at 09:55
  • Volatile variables are just to tell the jvm "Not to cache the state of a variable but flush it directly to the memory but it does not provide any semantics for threadSafety." It provides a weaker form of synchronization. Assume you have a long variable a (64 bit) and you do an assignment b = a. Then it happens as part of two step process and making it only volatile will not prevent it. Only synchronization can help. – Ouney May 29 '15 at 10:01
  • Accepted!!! I want to know "How can we achieve synchronization in variables?" – Anil Reddy Yarragonda May 29 '15 at 10:05
  • :). When i say that we need to use synchronization while accessing these variables. It means we have to access these shared variables in a synchronized block. – Ouney May 29 '15 at 10:06
  • synchronization needs the Lock but accessing Volatile variables should need any lock. Might be it will affect the performance?? – Anil Reddy Yarragonda May 29 '15 at 10:09
  • Synchronized method affects performance more than volatile keyword in Java. http://javarevisited.blogspot.com/2011/06/volatile-keyword-java-example-tutorial.html. See the difference between Synchronize and Volatile keyword part – Anil Reddy Yarragonda May 29 '15 at 10:11
  • Okay - From the blog you posted i got this line - "So if you want to share any variable in which read and write operation is atomic by implementation e.g. read and write in int or boolean variable you can declare them as volatile variable." Please note down the term atomic in there. So, instead of normal long if you have an AtomicLong which is declared as volatile then you do not need synchronization but normal variabled you do need it, – Ouney May 29 '15 at 10:23