if thread A start before thread B in java,then A will be scheduled by os before B?

The issue of "happened before" is not that it causes thread A to set the value before thread B. It is that although it may happen that thread A got to the this.value = value chronologically before thread B got to run getValue, the value B sees may still be the old value.

That is, in a threaded environment, even if two instructions are performed in chronological order, it doesn't mean that the results of one will be seen by the other.

If thread B happened to call the method first, it will always get the old value. But if it happened to call the method second, it's unknown if it gets the old or the new value.

For this reason, you have to use means to ensure the "happens before" rule, and then you know that the results of what "happened before" are seen by what "happens after".

So if value is volatile, for example, it ensures that if setValue() is called by thread A before thread B, then thread B will see the new value.

╔═════════════════════╤════════════════════════╤═════════════════════╗║ Order of operations │ Are we using           │ What value of value ║║                     │ volatile/synchronized? │ will B see?         ║╠═════════════════════╪════════════════════════╪═════════════════════╣║ A runs setValue(10) │ N                      │ Unknown             ║║ B runs getValue()   ├────────────────────────┼─────────────────────╢║                     │ Y                      │ 10                  ║╟─────────────────────┼────────────────────────┼─────────────────────╢║ B runs getValue()   │ N                      │ 0                   ║║ A runs setValue(10) ├────────────────────────┼─────────────────────╢║                     │ Y                      │ 0                   ║╚═════════════════════╧════════════════════════╧═════════════════════╝

Regarding your two questions:

1. True. You can't know which of them gets to that instruction first. It's not just the issue of which thread is scheduled first. The threads may be running on different CPUs, one CPU may need a long memory fetch, the other only a short memory fetch, so it is slower than the other. Also, it may be that the machine instructions in preparation for the code are of different length. In general, you simply don't know what is happening behind the scenes, and Java makes no guarantees about the order the threads run.
2. It's unlikely that instructions will be re-arranged in this particular case, because the methods are very short. Again, you can't tell what is happening because it is up to the particular JVM, number of CPUs, type of CPU, scheduler and memory arrangement - you have no guarantees.

Adding synchronized to the functions setValue/getValue implies that any thread that wants to execute that piece of code will first have to obtain (or wait) for a lock on that object.

If we assume no locks being held before Thread A calls setValue/getValue, Thread A will immediately get the lock. However, in the interim, if thread B calls setValue/getValue, it will have to wait for Thread A to relinquish the lock before it can execute the method.

However, had both the threads been waiting for a lock on the object, we cannot guarantee which one would have been first picked by the OS.