The parameter cannot "lose its value".

A parameter in a constructor (or method, static or otherwise) is really
a local variable in disguise, one that gets preassigned with the result
of evaluating some expression where the method or constructor got called.

What happens if I execute

Foobar f = new Foobar(someList)

private List myList;
public Foobar (List theList) {
        myList = theList;
}

is more or less as follows.

A reference "f" is allocated on the stack.
The expression "someList" is evaluated, presumably to a List reference
(under the hood this is most probably a machine pointer).
Memory for a new Foobar is allocated (here is where any OOME is thrown),
including for a reference "myList".
A reference "theList" is allocated on the stack.
The pointer to the list referenced by "someList" is copied to "theList".
The code being run jumps into the Foobar constructor's code.
The pointer at "theList" is copied to "myList".
At some time during all of this, the "f" reference is made to point to
the new Foobar object being constructed.

This is what happens conceptually; there may well be optimizations in
practise, especially with JIT compiling.

In any event, if "someList" is reassigned before the constructor is
called, the newer value is what gets copied to "theList"; otherwise the
older value is copied. (With concurrency, a race condition may make it a
toss-up which version gets copied.)

But "theList" gets one version or the other, and this version is copied
to "myList". If "someList" is changed to point to another List (or to
"null") after it was copied to "theList", "theList" still points to the
earlier List, and "myList" still ends up pointing to that List.

Maybe it's easier if an integer is used. A machine pointer and an
integer are probably the same thing at the bottom level, modulo the
hardware you use, anyway, but some things should be clearer.

So "someInteger" is equal to, say, 5. When the constructor is called,
"theInteger" gets set equal to 5. If "someInteger" is changed to 6 by
some concurrent code, "theInteger" remains equal to 5, because it's a
different integer; it's a copy. Eventually "myInteger" ends up being 5
(not 6).

The tricky case is when the object is mutable. So "someList" points to a
list, "theList" gets pointed to the same list, and someone adds
something to the list, then "myList" gets pointed to the list. Since
there's only the one list, the change is visible everywhere, but it
wouldn't have mattered. If the change happened before "theList" was
assigned, "myList" still ends up pointing to this list, and still it has
the extra item. If "myList" points to the list before the change is made
to the list, "myList" stays pointing to the same list, but someone
iterating over the list a couple of times with "for (Foo x : myList)"
may see a new item the second time they do so. This isn't peculiar to
constructors, and it wouldn't be prevented by making "theList" final, or
even by making "myList" final. This doesn't stop the list being
modified; it only stops the named reference being pointed at some other
list later, or becoming null.

Even using "Collections.unmodifiableList" somewhere along the way won't
stop someone changing the list that has a reference to the original list
object and not just the wrapper returned by the aforementioned method,
or make the list change invisible to "myList" users.

To make the list never get modified of course it can be wrapped in
"unmodifiableList" as soon as it's built and populated appropriately,
and all direct references to the original, mutable list discarded.

To make the Foobar constructor not see any modifications means passing
it a copy of the list: "Foobar f = new Foobar(new ArrayList(someList));"

To make the Foobar object unable to ever see any modifications the
constructor itself can copy the list: "myList = new ArrayList(theList);"

Even then the Foobar might have methods "return myList;" and then see
changes made to the list; "return Collections.unmodifiableList(myList);"
prevents that, and a single unmodifiable view can be constructed and
stored in an ivar to return instead of making a new one each time of
course. Either way the Foobar has a private copy of the list and doesn't
let anyone else ever get hold of a reference to it that can be used to
change it.

And even then, if the list contains objects that are themselves
modifiable, such as more lists, or sets or maps or whatever, one of
these might be altered and the change visible through the Foobar
instance's "myList" ivar.

Needless to say, it is often best to use unmodifiable object types,
including Collections.unmodifiableFoo, liberally, and encapsulate all
mutable state. Making ivars "final" helps make and enforce unmodifiable
object types.

Making constructor (or other) parameters "final" doesn't do anything of
the sort.

    It doesn't make much difference.  Personally, I declare
parameters as final if

    1) The consequences of changing them would be bad (which
       is seldom a concern in a pass-by-value language), or

    2) They will be used by inner classes created within the
       method (in which case Java *requires* them to be final).

Absent one or the other of these, I don't use final parameters:
they're just visual clutter, something that Java doesn't lack.

    If the constructor is doing so many things that it could
get confused, the constructor is probably doing too much.  Again,
opinions vary.  Most of my constructors consist of a little bit
of validation and then a few assignments to instance variables,
not enough code to offer a reading comprehension challenge.

    I don't feel that way.  A parameter without `final' is like
a fish without a bicycle.

Why?

If the constructor is so big that you can't /see/ that the parameter
is erroneously assigned, it's too big anyway. (And won't your unit
tests fail if you mess up the assignments?)

[...]

   As most poster have told you, it doesn't really make much pragmatic
difference either way.

   However, it seems most of these posters therefore conclude "don't
bother making your params final". I'm of the opposite opinion: Since it
doesn't matter either way, make them final by default. I like having as
many of my variables final as possible.

   - Oliver

On parameters, no it isn't. At least not in any sensible version. Really
early implementations did, but you shouldn't see them anymore. final is
displayed when applied to fields, methods and classes.

Tom hawtin