There is no scope limitation in terms of memory. When you have a read or write barrier it applies for all memory reads/writes.
Where I have seen a limitation is in memory mappings. When you memory map a file you have to be careful how you make this available to another threads as this new memory mapping might not be visible in another thread immediately resulting in a BUS error (and a crash of the JVM) This appears to be a OS bug as the newest versions of Linux and Windows don't appear to have this problem.
That implies that in the following code, two threads running method(), leaving the synchronized block will flush staticVar2 to the other thread, but not staticVar1, is that correct?
statixVar1 will always be flushed when staticVar2 is, perhaps sooner. No guarantee as to when, but the order is guaranteed.
If thread A executes method, then later thread B executes method2(), is the value of staticVar2 published from A to B, even though the two threads don't synchronize over the same lock?
Yes, the lock used doesn't matter for the happen-before guarantees.
Do volatile read-writes flush all memory to all threads, or only between the two accessing threads? Whichever the answer, is all memory flushed or only the volatile variables?
All dirty memory is flushed on a write barrier and all reads will be order consistent on a read barrier. volatile
performs both a write barrier on a write and a read barrier on a read.
Is all changed memory flushed when exiting a synchronized block, or just the memory that was changed within the block?
All of the memory changed by that thread.
Do all static variables accessed by two threads have to be synchronized?
Only if one thread modifies the variable. Any number of threads can read static values without synchronization.