Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have query about usage of Collections.synchronizedMap(Map m) over Hashtable. We know that both will return a container where all methods are synchronized, so I don't see performance gain in any case.
Then why we have utility method(Collections.synchronizedMap) when Hashtable suffice the requirement.
Clarification with code will be helpful.
Hashtable and Collections.synchronized() exist mainly for historical reasons. Since Java 5, the new java.util.concurrent package should be used in most cases where you need multiple threads accessing the same collection.
Collections.synchronized() is still useful when you receive a Collection (eg. from third party code) which is not thread safe and you want to share it between multiple threads, without creating a new, thread safe / concurrent collection.
Note that in most cases, you should use java.util.concurrent instead. Synchronized collections will protect their internal state by synchronizing all access to the collection, but that is inefficient in term of performance and does not address the larger problem of the coherence of your data. For example, ConcurrentHashMap provides a putIfAbsent() method that will ensure the atomicity of that operation.
There are more implementations of Map than just HashMap, and you might want to synchronize access to any of them.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have come across the following question multiple times:
What data structures are used in garbage collection?
I haven't found many resources about the data structures used in GC algorithms.
Edit: I understand that the question seems too broad since there are
different kinds of garbage collection techniques. We could go with the
commonly used garbage collection algorithms, like the ones found in
most popular JVMs.
Your question is rather like asking "how does an operating system work?" There are many different algorithms for GC and they use different internal data structures depending on how the algorithm works.
Many algorithms use a root set as a starting point. This is a list of all the objects directly accessible from your application threads. It is created by scanning the thread stacks, registers, static variables, etc. The GC will typically process the root set to follow links to other objects (that are therefore accessible) and build a graph of all accessible objects.
There are other data structures like card tables but these are not used in all algorithms.
You might want to pick a particular GC algorithm and study that.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am an intermediate-level Java programmer without any professional experience. I am wondering what the practical applications are of creating a specialized Object that implements Collection. For what reasons would one do this rather than simply using an existing Object like a LinkedList, HashSet, Queue, etc...?
Thanks!
There are many different implementations of Collection, each with their own special characteristics.
If you need a Collection with a different characteristic than any of the standard implementations in the Java Runtime Library, then you'd need to implement your own (or find a third-party library that already did it).
E.g. look at Apache Commons Collections™, or the collections in Guava for examples of collections with "non-standard" characteristics.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
everyone!
I am reading java doc from this:
https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html
Could anyone,please, tell more about
The Java programming language neither prevents nor requires detection
of deadlock conditions. Programs where threads hold (directly or
indirectly) locks on multiple objects should use conventional
techniques for deadlock avoidance, creating higher-level locking
primitives that do not deadlock, if necessary.
Thanks.
It means that "Do not expect java to handle OR avoid deadlocks for you. If you do not write your code properly then there is no way java will tell you in advance. So, it is your responsibility to make sure your code does not cause any deadlocks".
Basically, this paragraph states that Java won't handle deadlocks for you - it's your responsibility to avoid them.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Ok so I understand what synchronized does and I know that it should be used when two methods access the same piece of data.
Now I have Hibernate DAO methods which update and read from a database. None of the methods share any data objects although they do access the same database (So one of the methods updates it and others read from it). Should I synchronize these methods? Or should synchronized only be used for data objects and not data in a database?
Its nice if you synchronize your methods so when you writing data to the DB and same time your read method execute then there is possibilities that you will get old data in output not the currently updated data.
Thanks
You should synchronize if concurrent executions of the method in different threads may cause problems. If your method in itself is thread-safe (i.e. no shared data) it depends on whether the resources you are using in the methods are thread-safe.
In case of a Hibernate database I think synchronization is not necessary. (just a guess, without seeing the code). Hibernate and the Database itself are pretty good in keeping their data consistent. (provided your DB and Hibernate setup is OK)
One more point to consider: synchronized code always carries the danger of deadlocks. This is especially true if you keep resources locked for a long time, like a DB-call.
So, in short: without knowing more of your application and setup: I would not synchronize this method. (YMMV)
You should use locking in this place, When the first method update the data then only other method should read it.
http://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html
Whether your program will fail or not depends on how your code is organized and what it is trying to do.
However, sharing the connection among threads is not a good practice, as you face issues with transaction management and its associate isolation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Java 7 offers a wide range of different implementations of concurrent queues, namely:
java.util.concurrent.ArrayBlockingQueue<E>
java.util.concurrent.ConcurrentLinkedQueue<E>
java.util.concurrent.LinkedBlockingDeque<E>
java.util.concurrent.LinkedBlockingQueue<E>
Has anyone found any performance characteristics i.e. which one of those seem to be the fastest? I want to use one of the implementations for performance-critical section of my code.
There's no possible way to say which is the "fastest". That question doesn't make much sense. Fastest for what? You'd have to provide at least some amount of requirements. Garbage collection will have an effect. Caching behavior comes into play too and depends on data access patterns.
After determining that your performance requirements are not being met, and concretely identifying the container operations as a bottleneck via proper profiling and benchmarking, it is up to you to test and benchmark your own code in your own specific situations.
The concurrent collections generally exhibit the same high level performance characteristics as their vanilla counterparts.