<b>YES</b> Data visibility of atomic is guaranteed. The field doesn't need to be final nor volatile since it was created before the thread was started

<b>NO</b> Field initialization occurs in the thread and so might not be visible by the main thread. So the main thread might never go out of its loop.

<b>YES</b> In fact, all JUL are providing the necessary barriers to get the correct visibility.

<b>YES</b> Locking provides the same data visibility as synchronizing.

<b>YES</b> Finally, I slightly more complicated way using a volatile field ({@link #stopVolatileField}). Writing to the volatile field causes a happen

<b>NO</b> Data visibility to another thread is not guaranteed by a normal field. The child thread might never see {@link #stopNormalField} value chang

<b>YES</b> Two threads synchronizing on the same mutex are seeing the same thing inside the synchronized section.

<b>YES</b> Watch out. A lambda has not the same {@code this} as an inner class.

<b>NO</b> If the threads are not on the same mutex, there is no guarantee.

<b>NO</b> Data visibility of array elements is not guaranteed. Elements of a volatile array are not volatile.

<b>YES</b> Volatile ensure data visibility. When a volatile field is changed, all other threads are seeing the value right away.