3 ms·
All the time -- in Java, if you use java.util.concurrent, you don't have to deal with much of the complexity -- a LinkedBlockingQueue and producer-consumer patt
by jbooth 17y ago
All the time -- in Java, if you use java.util.concurrent, you don't have to deal with much of the complexity -- a LinkedBlockingQueue and producer-consumer pattern will solve 80% of real-world business threading problems just fine.
If you need to go beyond that, you've gotta make sure you understand the java memory model and the way monitors work -- or just put synchronized everywhere -- but that's still pretty straightforward once you get it all straight.
- Quarrelsome 17y ago"or just put synchronized everywhere" Won't you deadlock this way?
- jbooth 17y agoDepends on what you're doing. Synchronized locks on the instance (or class if you're using a static method) and the locks are reentrant -- a thread holding a lock can reacquire it as many times as it wants. But yeah my comment was a little imprecise :) If you're using a bunch of different objects which have interactions, using synchronized "everywhere" could very well lead to a deadlock :)
- GrandMasterBirt 17y agoThat statement was oversimplified. Its funny I've actually hit head on people who didnt understand "critical sections" and such and just added synchronized everywhere and even that didnt help because they were locking an independent object vs a shared object that had to be locked in order to create a critical section. So yea read up on multithreading, its extremely important to know, but hey my friend worked 4 yrs in .net and just started learning multithreading. So its not always needed.