About local final variables in Java
In java Program, parameters which is defined as String
in method declaration. But in method definition it is accessed as final String
variable. Whether it'll lead to some issues (like security, memory problem)?
For Example:
Method Declaration
开发者_StackOverflow社区join(String a,String b);
Method definition
public void join(final String a,final String b)
{
Authenticator au = new Authenticator(){
public PasswordAuthentication getPasswordAuthentication(){
return new PasswordAuthentication(a,b)}
};
}
Please help for me and clarify my doubts. Thanks in advance
P.S. I'm accessing a and b as final variable because I've got to use it in the inner class.
final
simply means that the reference/primitive variable can not be assigned a new value. It's not the same as const
concept (which Java doesn't have); it does NOT guarantee immutability. String
in Java, of course, is already immutable enough (barring nasty reflection attacks).
Using final
modifier for parameter arguments will have no effect on security or garbage collection. It's done for readability and to enforce coding convention that parameter variables aren't being reused in the method to store other values.
Upon encountering a final
modifier, a human reader can be assured that the value of this variable, once assigned, will not change within its scope. The compiler would enforce this behavior, and would not compile a program that illegally tries to assign a new value to variable that is declared final
.
JLS 14.2.4
final
VariablesA variable can be declared
final
. Afinal
variable may only be assigned to once. It is a compile time error if afinal
variable is assigned to unless it is definitely unassigned immediately prior to the assignment.
As mentioned, however, final
does not in itself guarantee immutability of the object being referred to. A final StringBuilder sb
declaration guarantees that sb
, once assigned and within its scope, will not refer to another StringBuilder
instance. StringBuilder
itself, of course, is a mutable object.
final
and inner classes
Another use of final
modifier is to allow local variables etc to be used by an inner class:
JLS 8.1.3 Inner Classes and Enclosing Instances
Any local variable, formal method parameter or exception handler parameter used but not declared in an inner class must be declared
final
.
This has to do with how inner classes using these variables are compiled in Java, an implementation detail that perhaps is not all too relevant for the discussion. Essentially, the values of these final
variables are given to the inner classes at construction time. Subsequent changes to the local variables (if allowed) would not be seen by the inner class instance. To ensure proper semantics, these local variables must thus be declared final
.
Effects of final
modifier for local variables at run-time
final
modifier for local variables/formal method parameters is a compile-time concept, and is not present at, say, the bytecode level (i.e. it plays a very different role than final
modifier for fields, classes and methods). Thus, this concept simply doesn't exist at run-time, where final
and non-final
local variables are indistinguishable; the usage of the keyword itself would not have any effect on garbage collectibility and/or performance.
Garbage collectibility is defined in terms of whether or not there are live references to an object. Local variables and method arguments go out of scope at the end of the method (or the block they're declared in), regardless of whether or not they're declared final
. Going out of scope means the reference is "dead". The object itself may still have live references from elsewhere.
In this particular case, the formal method parameters are declared final
so that they can be used in an inner class. As mentioned above, the inner class would copy these references for its own use. Thus, in this particular case, the Authenticator
object would have references to the String
objects referred to by a
and b
.
Simplistically speaking, the more references to an object there are, the harder it would be to qualify as garbage illegible for collection. The underlying factor, however, is the liveness of these references, not whether or not they're final
.
On profiling
It's good to understand the concepts to clear any doubts on memory usage/performance issues; it's better to just profile and see if the issues are real, and fix them as necessary. A well-designed system should be highly adaptable to these kinds of changes.
No, the final
on an argument only influences the local copy of the argument on the stack frame of the method. It does not in any way influence or change the value passed as an argument.
Making the variables final
does not have anything to do with security or memory allocation. It does not have any impact on security or memory use.
Adding final
doesn't change the signature or create any other issues. Thus, it is fine to use in a method specified by an interface (for instance). It only makes a difference to code inside the method.
精彩评论