4 ms·
The only part I found interesting was the first part, but only because it raises an interesting question that the author (unfortunately) didn't address: Suppos
by CodeMage 16y ago
The only part I found interesting was the first part, but only because it raises an interesting question that the author (unfortunately) didn't address:
Supposing you want to synchronize only one part of your method, which approach would cause the JVM to do less work: putting that part in a synchronized block (thus generating extra bytecode instructions) or extracting it into a synchronized method (thus generating an additional call)?
Not that it's really important -- micro-optimizations like that are silly -- but it does make me curious.
- drblast 16y agoThe article really fails here, this is a horrible example and horrible reasoning. I'm no Java expert, but the reason you'd synchronize a smaller block of code, or use any finer grain lock, rather than a whole method is that you'd have a shorter time to wait if many threads are competing for the lock. You'd increase utilization. Lines of bytecode doesn't really tell you anything, especially since the synchronized method is a stub that does nothing. Not only that, but the synchronized method does all its synchronization work implicitly; the JVM still has to acquire the lock somehow, it's just not written in the bytecode. What really matter is what happens when the bytecode is compiled to native code, so you could see the synchronized method call overhead. If the article analyzed that, it would be helpful.