static array variables would need to be locked?

so let's say that I have a static variable, which is an array of size 5. And let's say I have two threads, T1 and T2, they both are trying to change the element at index 0 of that array. And 开发者_如何学运维then use the element at index 0. In this case, I should lock the array until T1 is finished using the element right?

Another question is let's say T1 and T2 are already running, T1 access element at index 0 first, then lock it. But then right after T2 tries to access element at index 0, but T1 hasn't unlocked index 0 yet. Then in this case, in order for T2 to access element at index 0, what should T2 do? should T2 use call back function after T1 unlocks index 0 of the array?

Synchronization in java is (technically) not about refusing other threads access to an object, it about ensuring unique usage of it (at one time) between threads using synchronization locks. So T2 can access the object while T1 has synchronization lock, but will be unable to obtain the synchronization lock until T1 releases it.

You synchronize (lock) when you're going to have multiple threads accessing something.

The second thread is going to block until the first thread releases the lock (exits the synchronized block)

More fine-grained control can be had by using java.util.concurrent.locks and using non-blocking checks if you don't want threads to block.

1) Basically, yes. You needn't necessarily lock the array, you could lock at a higher level of granularity (say, the enclosing class if it were a private variable). The important thing is that no part of the code tries to modify or read from the array without holding the same lock. If this condition is violated, undefined behaviour could result (including, but not limited to, seeing old values, seeing garbage values that never existed, throwing exceptions, and going into infinite loops).

2) This depends partly on the synchronization scheme you're using, and your desired semantics. With the standard synchronized keyword, T2 would block indefinitely until the monitor is released by T1, at which point T2 will acquire the monitor and continue with the logic inside the synchronized block.

If you want finer-grained control over the behaviour when a lock is contended, you could use explicit Lock objects. These offer tryLock methods (both with a timeout, and returning immediately) which return true or false according to whether the lock could be obtained. Thus you could then test the return value and take whatever action you like if the lock isn't immediately obtained (such as registering a callback function, incrementing a counter and giving feedback to a user before trying again, etc.).

However, this custom reaction is seldom necessary, and notably increases the complexity of your locking code, not to mention the large possibility of mistakes if you forget to always release the lock in a finally block if and only if it was acquired successfully, etc. As a general rule, just go with synchronized unless/until you can show that it's providing a significant bottleneck to your application's required throughput.

I should lock the array until T1 is finished using the element right?

Yes, to avoid race conditions that would be a good idea.

what should T2 do

Look the array, then read the value. At this time you know noone else can modify it. When using locks such as monitors an queue is automatically kept by the system. Hence if T2 tries to access an object locked by T1 it will block (hang) until T1 releases the lock.

Sample code:

private Obect[] array;
private static final Object lockObject = new Object();

public void modifyObject() {
    synchronized(lockObject) {
       // read or modify the objects
    }
}

Technically you could also synchronize on the array itself.

You don't lock a variable; you lock a mutex, which protects a specific range of code. And the rule is simple: if any thread modifies an object, and more than one thread accesses it (for any reason), all accesses must be fully synchronized. The usual solution is to define a mutex to protect the variable, request a lock on it, and free the lock once the access has finished. When a thread requests a lock, it is suspended until that lock has been freed.

In C++, it is usual to use RAII to ensure that the lock is freed, regardless of how the block is exited. In Java, a synchronized block will acquire the lock at the start (waiting until it is available), and leave the lock when the program leaves the block (for whatever reasons).

Have you considered using AtomicReferenceArray? http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/atomic/AtomicReferenceArray.html It provides a #getAndSet method, that provides a thread safe atomic way to update indexes.

T1 access element at index 0 first, then lock it.

Lock first on static final mutex variable then access your static variable.

 static final Object lock = new Object();
 synchronized(lock) {
   // access static reference
 }

or better access on class reference

synchronized(YourClassName.class) {
     // access static reference
}