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

Question

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().

Solution 1

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.

Solution 2

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.

Comments

[Mike Blandford]

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 :)

[Edmondo]

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"

[Kip]

well that may be, but no one here has written or suggested a microbenchmark...

[Ben Page]

@Mike Blandford's answer suggests using a micro-benchmark does it not?

[Edmondo]

Writing micro benchmarks in Java is something very very tricky

[Xairoo]

The question was about parameters being declared final, which has no performance impact.

[John Gardner]

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...

[kohlerm]

On modern JIT'S (Hotspot) final does not have any (measurable) performance influence at all, whether applied to parameters or the class

[ron]

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.

[RAY]

"It's pretty rare that bugs are caused by a parameter being unexpectedly assigned". It's more common than you think...

[Dobes Vandermeer]

@RAY you might be right, actually I don't have any data (beyond my own experience) to back up that claim.

[Christopher Schultz]

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.

[Xairoo]

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 ;-)

[swooby]

@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.

[user207421]

The question isn't about private statc final variables.