Don't getters returning objects allow callers direct access to member variables?

Let's say I have a simple class that stores a user's friends in an ArrayList of strings, with a getter to access that ArrayList:

public class User
{
  private ArrayList<String> mFriends;
  
  // ...other code like constructors and setters...

  public ArrayList<String> getFriends()
  {
    return mFriends;
  }
}

Since Java and many other languages are (equivalently) pass-by-reference, does this not allow the caller of getFriends() direct access to my ArrayList of strings i.e. they could modify it without even calling my setter?

I feel this immensely breaks the concept of encapsulation. Is there a normal workaround for this, besides dynamically creating a new ArrayList with the same values and returning that, or am I misunderstanding something?

Edit: I understand that Java is not truly pass-by-reference but rather passes over a copy of the address of the original object, but this has the same effect as pass-by-reference when exposing objects to those outside your class

1. Java is not, and has never been implementing Pass by Reference mechanism, it has always been Pass by Value;
2. The problem you are describing is known as Reference Escape, and yes, you are right, caller can modify your object, if you expose it via reference;
3. In order to avoid the Reference Escape problem, you can either:
   1. return a deep copy of the object (with .clone());
   2. create a new object with the existing data (e.g. new ArrayList<>(yourObjectHere));
   3. or come up with some other idea, there are some other ways too do this;
4. This does not really break the Encapsulation, per se, it is rather a point of correct design how you implement the encapsulation;
5. Your concern about performance: no, it is not going to break performance, moreover - it has nothing to do with performance; rather it is a matter of proper design of the OOP, mandating either mutability or immutability of the object. If you were to always return a deep copy instead of reference, you would not have a chance to have a good leverage of your object.
   <br>Taking your example: what if you want to change the state of the object without just setting a new object via its setter? what if you want to amend the existing friends (which is in your example)? do you think it is rather better to create a new List of friends and set it into the object? no, you are simply losing control over your object in the latter case.

If you are worried about encapsulation then you can return a copy of your list e.g.

public ArrayList<String> getFriends() {
    return new ArrayList<>(mFriends);
  }

By the way, Java is not truly pass-by-reference it's more pass-by-value.

You are right for mutable objects. You could wrap the field with Collections.unmodifiableList and such. What one also sees, is for (mutable) collections just have no getters, but addFriend, getFriend(index) and such.

In fact getters (and estpecially setters) are no longer a very esteemed pattern.

The member "m" prefix is imho better suited for other languages.