How do lambdas store references to variables

I feel that this is an easy question but I was unable to find answer. After executing this simple code:

public class MyClass {
    
    int value;

    static interface MyFunctionalInterface {
        void foo();
    }

    public static void main(String args[]) {
       MyClass xxx = new MyClass();
       MyFunctionalInterface myLambda = () -> System.out.println("Value: " + xxx.value);

       xxx.value = 777;
       myLambda.foo();
       
       xxx.value = 888;
       bar(myLambda);
    }
    
    static void bar(MyFunctionalInterface myLambda) {
        myLambda.foo();
    }

}

The result (as expected) is just:

Value: 777
Value: 888

My question is about xxx object. How does the lambda store reference to this object? Is there some anonymous class created which stores "Value: " string and xxx object? This object still exists in bar function, so it has to be stored somehow somewhere.

Edit:
Basing on hint from @Sweeper it can be concluded that lambdas store references to such variables inside themselves.
If (with above code) we print:

System.out.println(Arrays.toString(myLambda.getClass().getDeclaredFields()));

we will get:

[private final MyClass MyClass$$Lambda$1/0x0000000800000c08.arg$1]

However, if code is modified and lambda created without xxx:

MyFunctionalInterface myLambda = () -> System.out.println("Just string");

Then declared fields will be empty and it will print just "[]"

First let me just doublecheck that you understand the way java references and objects work or the explanation isn't going to make any sense:

> MyClass xxx = new MyClass();

This [A] reserves some space on the heap large enough to store 1 instance of MyClass, [B] constructs a new instance of MyClass into that space, and then [C] assigns the pointer pointing at the location where this object now resides on the heap to xxx. Because 'pointer', from C, kinda implies you can e.g. increment it or print it, as an encore, we shall not call it a 'pointer' and instead we call it a 'reference'. But, it's.. a pointer.

> xxx.value = 777;

This doesn't 'change' anything - xxx. is 'take variable xxx, follow the pointer, then go change stuff over on the heap. Which, crucially, means xxx does not change. Only the object xxx is pointing at is being changed here.

Thus, xxx is effectively final throughout this method. It's a constant. Which means the only thing we need to do here is ensure the lambda continues to know about it. Given that a lambda can 'outlive' the context of the method it is created in, this is a bit of an issue: Ordinarily, local variables (and method parameters are a kind of local var) are declared on stack and therefore poof out of existence when a method ends. Clearly then, xxx cannot live there. At least, not the one the lambda uses.

Java solves this problem not in the way most languages do. Most languages realize xxx has to outlive the method and 'hoist it onto the heap'. Java doesn't do this (after all, things that live on heap, or can escape via lambdas to other threads, all of a sudden need to answer hairy questions such as "does that mean local variables can now be marked volatile?"). Instead, java just clones it. Because clones would get real confusing if code also modifies the variable (which of the clones are you modifying?), your code wouldn't even compile unless xxx is final! - the one 'gift' java gives you is that if your variable could have been marked as final without causing issues, i.e. you only write to it once, then you can omit final and java will just assume it. Try it! Take that code and reassign xxx anywhere (in the lambda or outside of it; does not matter), and you'll get an error that you can't use xxx in the lambda at all as it is not 'effectively final' (the java spec's term for "either marked final, or could have been so marked without issue").

So now it's simply: xxx in the context of the method itself remains a stack-allocated variable as normal. And the lambda gets a clone of it, which.. yes, lives on heap. There is an object representing this lambda that contains its captured state. Javac knows that only the variables actually used by the lambda need capturing (which may include this!), and captures only what is needed.

Lambdas which capture zero state are special in that they don't need an object at all to represent their state. Instead, those end up, effectively, as static methods and the lambda exists as a MethodRef object at the class/JVM level.

Regardless of whether your lambda has state or not, you should never use the object identity of one; the JVM spec says your code won't straight up crash but whether that identity has a meaningful uniqueness is not guaranteed. In other words, don't use them as keys in maps, don't lock on them (synchronized). Don't == them.