This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
The "memory model" is a rather specialized issue that is important in the following circumstances:
1) You have a computer with more than one CPU 2) Your Java program has multiple threads 3) Your threads simultaneously access the same memory values
Funny things can happen in these circumstances because each processor has its own cache. (RAM is quite slow compared to a modern CPU, so the CPU caches frequently accessed memory locations.) Each processor might use a different value for what should be the same memory location.
Also, the JIT compiler may reorder instructions in one thread, which may mess up assumptions about instruction order that another thread makes. For example, if one thread never modifies a variable, the compiler may only read it from memory once. Then the other thread's modification of the same variable becomes invisible.
The memory model gives precise rules when the JVM needs to ensure that variables are properly shared between threads (e.g. in a synchronized block or if the variables are volatile), and when the processor and the compiler are free to carry out optimizations.
It is probably the dullest JSR out there, but of course, this is important stuff, and I am glad that some people worry about it.
Application programmers probably shouldn't worry about it too much. My advice is: 1) Try to use the new threadsafe collections in JDK 5.0. The implementors have done all the thread-safety grunt work for you. 2) If there are no collections that work for your task, use synchronization or the new JDK 5.0 locks and conditions 3) If that's too much trouble (e.g. to access a single shared int), use volatile
That is to say, in case my applications are distributed and multithreaded, the JVM will cater all memory issues for me, and what I need to do is to make sure that the Objects used in the system is thread-safe?
For non-multithreaded applications, are there any impact on them?
Recently, I havent developed any non-Web-based applications, and I guess the multithreading issues are handled by the container, in case, J2EE Tiger released, which I suppose it will use the same memory model, the container might have less effort for handling these issues?
Joined: Nov 14, 2004
Absolutely... Ideally you shouldn't have to worry much about it, particularly if you can have the container handle transactions. The people who implement the container will really appreciate the new multithreading features.
Joined: Nov 07, 2003
Did you have any reference/articles about this area?