Does the following Java program must print "num:1 m_i:2 " because of synchronization order

I just want to check if my understanding of the JMM's thread start synchronization rule is correct:

Does the following Java program must print "num:1 m_i:2 " just because of the following synchronization order.

http://java.sun.com/docs/books/jls/third_edition开发者_如何学Go/html/memory.html#17.4.4

An action that starts a thread synchronizes-with the first action in the thread it starts.

public class ThreadHappenBefore {
    static int num;
    int m_i;

    public static void main(String[] args) {
        final ThreadHappenBefore hb = new ThreadHappenBefore();
        num = 1;
            hb.m_i = 2;

        new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println("num:"+num);
                System.out.println("m_i:"+hb.m_i);
            }
        }).start();
    }
}

Anything coded before other code is guaranteed to happen before the other code in a given thread when the earlier code has an effect on the later code. Because the thread start is coded after the assignments, and the assignments affect the outcome of the print statements, these assignments are "visible" (ie happened before) the the code that prints them.

However, there is no such guarantee made to the effects of order of execution when viewed from another thread.

EDITED (thanks to commenters)

Added a refinement (in bold) to the above regarding reordering.

I don't think u have a synchronize issue here you will have the result u expect because of the code order. synchronize issue can occur if you have several threads referring to same source

Since so far nobody except Stephen C in a comment has posted the correct answer: The creation of a thread (the start() not the new Thread()!) ensures a happens-before relationship.

If this was not the case, the JVM could easily reorder the instructions as long as it can guarantee that the own thread wouldn't see a difference.

You can be pretty sure that in every language with a sensible multithreaded memory model that there will be some memory barrier for this case, because otherwise you couldn't reliably pass parameters to a thread.

No, it prints the right thing because of the "happens-before" relation in section 17.4.5. If you look at the discussion below the section, it is also clearly stated:

A call to start() on a thread happens-before any actions in the started thread.

and furthermore:

If x and y are actions of the same thread and x comes before y in program order, then hb(x, y).

Therefore the two assignments are guaranteed to have happened before the read in the thread.

You have no synchronization in your example.

What 'synchronization order'? There is no synchronization here. This is just normal excecution order. All the assignments occur before the thread even starts. I don't know why this is considered mysterious.