120

Is there any performance reason to declare method parameters final in Java?

As in:

public void foo(int bar) { ... }

Versus:

public void foo(final int bar) { ... }

Assuming that bar is only read and never modified in foo().

codeforester
  • 39,467
  • 16
  • 112
  • 140
Kip
  • 107,154
  • 87
  • 232
  • 265
  • 1
    I would suggest you never write micro benchmarks. You do not know which optimization the JIT can do and when, and you would likely get a wrong idea of how it behave just doing a "simple test case" – Edmondo Aug 18 '11 at 09:45
  • well that may be, but no one here has written or suggested a microbenchmark... – Kip Aug 19 '11 at 00:29
  • 1
    @Mike Blandford's answer suggests using a micro-benchmark does it not? – Ben Page Sep 12 '11 at 12:46
  • Writing micro benchmarks in Java is something very very tricky – Edmondo Apr 24 '12 at 06:54
  • I can't think of a reason why the compiler would care if you declared a method parameter final or not. But the real answer to this question is - write two functions, one with final parameters and one with regular parameters. Run them a million times each and see if there's any noticeable runtime difference. If you're worried about performance, it's very important to do some profiling work on your code and find out exactly what is slowing you down. It's almost certainly not what you would expect it to be :) – Mike Blandford Nov 05 '08 at 21:57

5 Answers5

100

The final keyword does not appear in the class file for local variables and parameters, thus it cannot impact the runtime performance. It's only use is to clarify the coders intent that the variable not be changed (which many consider dubious reason for its usage), and dealing with anonymous inner classes.

There is a lot of argument over whether the final modifier on the method itself has any performance gain since the methods will be inlined by the optimizing compiler at runtime anyway, regardless of the modifier. In this case it should also only be used to restrict the overriding of the method.

Sinthia V
  • 2,103
  • 2
  • 18
  • 36
Robin
  • 24,062
  • 5
  • 49
  • 58
  • 6
    you'd think that final variables/params could be optimized as loop variables though...but a good compiler/runtime should be able to figure that out without final anyway... – John Gardner Nov 05 '08 at 22:57
  • 10
    I have seen Sun's compiler emit marginally shorter bytecode when the only difference between the two methods has been the "finality" of local variables. Micro-optimizations are a real thing, and compilers do actually make them. What really matters, of course, is what the JIT does with the bytecode, and local references lose their "finality" when compiled to bytecode. I think this is why there is so much speculation about final local variables: it's quite non-deterministic what the results are. However, using final locals can affect the bytecode -- for what it's worth. – Christopher Schultz Aug 09 '13 at 16:33
  • As it is non deterministic, there really isn't any way to depend on the optimization either. Of course, a lot may have changed in the VM implementations since the original answer in 2008 ;-) – Robin May 07 '15 at 22:52
15

The only benefit to a final parameter is that it can be used in anonymous nested classes. If a parameter is never changed, the compiler will already detect that as part of it's normal operation even without the final modifier. It's pretty rare that bugs are caused by a parameter being unexpectedly assigned - if your methods are big enough to need this level of engineering, make them smaller - methods you call can't change your parameters.

Dobes Vandermeer
  • 8,463
  • 5
  • 43
  • 46
  • 8
    "It's pretty rare that bugs are caused by a parameter being unexpectedly assigned". It's more common than you think... – RAY Feb 22 '12 at 08:46
  • 2
    @RAY you might be right, actually I don't have any data (beyond my own experience) to back up that claim. – Dobes Vandermeer Feb 23 '12 at 10:46
  • @DobesVandermeer to be more precise, that isn't really a "benefit to a final *parameter*". What you are describing is simply required syntax for any local variables (of which I am including parameters as) to be made visible to the local scope of the anonymous nested class. – swooby Mar 15 '17 at 20:07
0

Just one more point that to above that using non-final local variables declared within the method—the inner class instance may outlive the stack frame, so the local variable might vanish while the inner object is still alive

user666
  • 1,104
  • 12
  • 20
-1

Compilers that operate after class loading, such as JIT compilers, can take advantage of final methods. Consequently, methods declared final could have some performance benefit.

http://www.javaperformancetuning.com/tips/final.shtml

Oh and another good resource

http://mindprod.com/jgloss/final.html

branchgabriel
  • 4,241
  • 4
  • 34
  • 48
  • 10
    The question was about parameters being declared final, which has no performance impact. – Robin Nov 05 '08 at 22:24
  • On modern JIT'S (Hotspot) final does not have any (measurable) performance influence at all, whether applied to parameters or the class – kohlerm Nov 06 '08 at 10:08
  • 2
    The two articles you link both suggest that final is rather a semantic mark for the developers, and that the JIT compilers may use final (but as others pointed out, they don't really need that info). So final is rather semantic, which is in parallel with modern C/++ compilers ability to infer constness of variables and methods even if they are not marked const explicitly. – ron Mar 06 '11 at 17:42
-2

I assume the compiler could possibly remove all private static final variables that has a primitive type, such as int, and inline them directly in the code just like with a C++ macro.

However, i have no clue if this is done in practice, but it could be done in order to save some memory.

user1402866
  • 11
  • 2