Stack Confinement using local object reference

Question

I am following Java Concurrency in Practice, and when I read about stack confinement I felt good because it explained very well, but this statement raised some doubts for me:

Maintaining stack confinement for object references requires a little more assistance from the programmer to ensure that the referent does not escape

Can anyone do something in below code to produce a violation of stack confinement? I guess it has no confinement violation at present. I want to know how local object reference can violate the confinement.

/**
 * 
 */
package lession2.shared.object;

/**
 * @author so_what
 */
class Person {
    private String personName;
    private String personAddress;

    public String getPersonName() {
        return personName;
    }

    public void setPersonName(String personName) {
        this.personName = personName;
    }

    public String getPersonAddress() {
        return personAddress;
    }

    public void setPersonAddress(String personAddress) {
        this.personAddress = personAddress;
    }

    @Override
    public String toString() {
        return "Person [personName=" + personName + ", personAddress=" + personAddress + "]";
    }
}

public class StackConfinement extends Thread {

    public void setSomeMoreProperty() {
        //this person object will be confined to each thread
        Person person=new Person();
        person.setPersonAddress("NY");
        person.setPersonName("Xyz");
        //now I wan to pass this person to the other method
        doSomething(person);
        System.out.println(person);
    }

    public void doSomething(Person person) {
        person.setPersonAddress("Canada");
        //can one add some thing here and violate the thread confinement
    }   

    @Override
    public void run()
    {
        setSomeMoreProperty();
    }

    public static void main(String[] args) throws InterruptedException {
        StackConfinement thread1=new StackConfinement();
        StackConfinement thread2=new StackConfinement();
        thread1.start();
        thread2.start();
        thread1.join();
        thread2.join();
    }

}

Answer 1

this statement raised some doubts for me:

Maintaining stack confinement for object references requires a little more assistance from the programmer to ensure that the referent does not escape

Can anyone do something in below code to produce a violation of stack confinement?

Of course. If this were not a thing then Goetz et al. would not have spent time on stack confinement in the first place.

I guess it has no confinement violation at present. I want to know how local object reference can violate the confinement.

A reference stored in a local variable does not violate stack confinement, which the book defines as the situation in which an object can be reached only through local variables. The problem arises when there is a(nother) reference to the object that is more broadly reachable. That would happen, for example, if you store a reference to object in a static field of any class. It also happens if you store a reference to the object in a container that is not itself stack confined.

The book gives the example of a more subtle case in which a reference is stored in a container that itself is initially stack-confined, but later is published. Since the object is reachable from the (no longer stack-confined) container, it is no longer stack-confined either.

There are literally an infinity of ways in which stack-confinement violations could be introduced into your particular code, but how about this: suppose I wanted to make StackConfinement.setSomeMoreProperty() actually have a persistent effect, such as putting the Person objects it generates into a List. That would look like this:

public class StackConfinement extends Thread {

    private List<Person> people = new ArrayList<>();

    public void setSomeMoreProperty() {
        // Initially stack-confined
        Person person = new Person();

        person.setPersonAddress("NY");
        person.setPersonName("Xyz");

        // does not break stack confinement:
        doSomething(person);
        System.out.println(person);

        // this DOES break stack confinement:
        people.add(person);
    }

    // ...
}

That's all well and good, but now neither the people member nor any object it references (such as the person that is added by setSomeMoreProperty()) is stack-confined.