ConcurrentHashMap's putifAbsent() method

Hi ,
I am trying to use ConcurrentHashMap's putifAbsent() method .
But my requirement is that :
The value passed to this method is a new object . I would like to avoid creating new object , when the map has the key already.
For example:
my code is like this .
map.putIfAbsent(key, new Object());
I would like to avoid creating new Object() when the key is already present in the map.
How can I achieve this ?
Any suggestion would be helpful.
Tutika

Then employ proper thread synchronization. You do know
what the "synchronized" block is for, right? The whole point of ConcurrentHashMap is to avoid synchronizing in order to increase utilization of a multi-cpu computer.
Thanks for your reply. Will it not give any multi
threading issues ?
Object x = map.get(key);
if (x == null) // it wasn't there, so do your thing
If 2 threads arrive at (x== null) , 2 objects will be
created for me . I would like to avoid it .
Map will be having only one value .but 2 objects will
be created.The above code or putIfAbsent() will created multiple objects. You have to decide if that is really a problem. When going for concurrency in order to maximize utilization of multiple CPUs, you have to make some trade offs. If the Object being created light, it shouldn't be a problem creating multiples copies of it. You have much better concurrency than synchronizing. One will get in the map the other will just get quickly discarded.
If it is critical that the Object not be created than you can add levels of indirection or take the concurrency hit and due synchronization as suggested by warnerja. Then you might as well not use the ConcurrentHashMap.
One level of indirection is to create a lightweight wrapper Object that goes into the ConcurrentHashMap that will contain your real value. Compare it to the Object returned by putIfAbsent (In this case you can use the == operator). If it is the same object then create the Real value object and put it in the wrapper. Just beware that other threads may get an empty wrapper until this operation completes.
Another thing you can do is to look at the source code of putIfAbsent and create extend ConcurrentHashMap and create another method like putIfAbsent that takes an interface that can call back on a method of that interface when a new object is needed. Something like:
interface ObjectCreator<T> {
  T createObject();
class MyConcurrentHashMap<K,V> extends ConcurrentHashMap {
    public V putIfAbsent(K key,ObjectCreator<V> objectCreator) {
        // This is like the regular putIfAbsent except
        // don't add objectCreater,  Add object returned by
        // objectCreator.createObject() if object is going to
        // be added to the map
void myCode() {
  map.putIfAbsent(
      key,
      new ObjectCreator<Object>() {
        Object createObject() {
           return new Object();
  );

Similar Messages

  • Withholding creation of value in using putIfAbsent() of ConcurrentHashMap

    Hi,
    What would be the best and thread safe implementation if I use putIfAbsent() method of ConcurrentHashMap in such a way that the value I am putting is only created if the Map does not contain the key? Our Object (used as a Map Entry value) is expensive to create and if an entry is already present do not want to create a new one. Instead of using synchronizedMap and locking the entire Map I would like to take advantages of ConcurrentHashMap.
    In the following sample I would like StringFactory.createNew() to be only called if the chm does not contain the "key" or else return the value it already has.
    public class CHMTest {
    @Test
    public void testConcurrentHashMap() {
    ConcurrentHashMap chm = new ConcurrentHashMap();
    for (int i = 0; i < 3; i++) {
    System.out.println(chm.putIfAbsent("key", StringFactory.createNew()));
    private static class StringFactory {
    public static String createNew() {
    System.out.println("Creating a new String -- Very Very expensive");
    return UUID.randomUUID().toString();
    }

    jtahlborn wrote:
    jverd wrote:
    I ususally do:
    if (!map.containsKey(x)) {
    map.putIfAbsent(x, new ExpensiveThingy());
    }It does require two tests (sort of a twist on DCL), but there's no explicit syncing necessary, and about as small performance hit as you can get.that's almost my first example (above), Yeah, I noticed that. :-) Just adding one more (albeit almost identical) option.
    however, how do you actually get the value? if you do another get() after this, you're doing more work than you need to by using containsKey().Right. I find this idiom:
    if (!map.containsKey(x)) {
      map.putIfAbsent(x, new ExpensiveThingy());
    ExpensiveThingy et = map.get(x);easiest to write and read, so that's what I usually do. I doubt the extra get is significant in most cases, and it keeps the code cleaner than with the syncing needed for the get() approach.
    (I also have the habit of using containsKey() over get() == null because a) it describes exactly what I'm trying to do and b) get() returning null can mean the key is present with a null value--even though this doesn't happen in any map I can ever recall using, and is not even allowed by ConcurrentHashMap as far as I know. Just a habit.
    EDIT:
    To expand a bit. With your first example:
    Object result = map.get(key);
    if(result == null) {
      // ... create newValue ...
      map.putIfAbsent(key, newValue);
    }We have to either sync or call get again. We can't use newValue, because we don't know that another thread hasn't come in between our null test and our put() call and put() its own entry. Using get() doesn't save anything over containsKey(), if I'm not missing something.
    Edited by: jverd on Oct 18, 2011 10:15 AM

  • ConcurrentHashMap.putIfAbsent efficiency question

    Hi,
    I have a question for the putIfAbsent method of ConcurrentHashMap. according to API, this is atomic. so just consider the following two segments of code:
    ConcurrentHashMap<Key, Value> map;
    ReentrantLock lock;
    1.
    Object obj = new Object();
    Object oldObj = map.putIfAbsent(key, obj);
    if(oldObj!=null) obj = oldObj;
    2.
    lock.lock();
    try{
    Object obj = map.get(key);
    if(obj==null){
    obj = new Object();
    map.put(key, obj);
    } finally {
    lock.unlock();
    I am new to the concurrent package and thus don't know the performance issues. For approach 1 I think the potential problem is Object creation everytime no matter the Object exists in the map or not. Would anyone tell me which will have better performance when the map contains lots of objects and the map insert rate is very high?
    Thanks,
    Benny

    Using Locks is hard and errorprone, use ConcurrentHashMap and other collections since inventing your own locking mechnism would be difficult.
    If you manage to implement your own fast locking mechnism for hashmaps you want to publish it in a Academic Paper so others can implement it too. Like that ConcurrentLinkedQueue that is based on a paper from 1996 http://www.cs.rochester.edu/u/michael/PODC96.html.

  • Concurrent, non-synchronized, lazy initialization: is this correct?

    Guys, I would appreciate a sanity check on some code of mine.
    I have a class, call it State. Every instance is associated with a key of some type. Each user will know the key it wants to use. It will present that key to State to request the corresponding State instance. They must always receive back that sole instance that corresponds to key. The keys are unknown until runtime, so you must lazy initialize a State instance when first presented with a given key.
    If concurrency was not an issue, then State could have lazy initialization code like this:
         /** Contract: never contains null values. */
         private static final Map<Object,State> map = new HashMap<Object,State>();
         public static State get(Object key) {
              State state = map.get(key);
              if (state == null) {
                   state = new State();
                   map.put(key, state);
              return state;
         private State() {}     // CRITICAL: private to ensure that get is the only place instances createdBut heavy concurrency on get is present in my application. While I could trivially make the above code safe by synchronizing get, that would cause it bottleneck the entire application. Vastly superior would be the use of some sort of concurrent data structure that would only bottleneck during the relatively rare times when new State instances must be created, but would allow fast concurrent retrievals when the State instance has already been created, which is the vast majority of the time.
    I think that the unsynchronized code below does the trick:
         /** Contract: never contains null values. */
         private static final ConcurrentMap<Object,State> map = new ConcurrentHashMap<Object,State>();
         public static State get(Object key) {
              State current = map.get(key);
              if (current != null) return current;
              State candidate = new State();
              current = map.putIfAbsent(key, candidate);
              return (current == null) ? candidate : current;
         }Here is how it works: most of the time, just the first two lines
         /** (ignore this) */
         State current = map.get(key);
         if (current != null) return current;will be executed because the mapping will exist. This will be really fast, because ConcurrentHashMap is really fast (its always slower than HashMap, but maybe only 2X slower for the scenario that I will use it in; see [https://www.ibm.com/developerworks/java/library/j-benchmark2/#dsat] ).
    If the relevant State instance is not present in map, then we speculatively create it. Because get is unsynchronized, this may/may not be the one actully put on map and returned by the subsequent lines of code because another thread supplying the same key may be concurrently executing the same lines of code. That's why its named candidate.
    Next--and this is the real critical step--use ConcurrentMap's atomic putIfAbsent method to ensure that just the first thread to call the method for a given key is the one who suceeds in putting it's candidate in map. We reassign current to the result of putIfAbsent. Its value will be null only if there was no previous mapping for key but this call to putIfAbsent suceeded in putting candidate on map; thus, candidate needs to be returned in this case. But if current is not null, then some other thread with the same key must have been concurrently calling this code and was the thread which suceeded in putting its State on map; thus in this case current will have that other thread's value and so return it (with this thread's candidate being a waste; oh well).
    Note that this problem is similar in spirit to the infamous double checked locking idiom. Since that is such a treacherous minefield
    [http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html].
    I would really appreciate another set of eyes looking over my code.

    Hi Bbatman,
    Thank you so much for your answer.
    Pietblock: I believe that your double checked locking proposal is still wrong.OK, I do believe you.
    Did you read the link that I provided in my initial post?
    It discusses some known solutions,
    the best of which for singletons is a value helper class,
    followed by making the reference to your singleton be volatile
    (assuming that you are using jdk 1.5+).Yes, I did read that article some time ago, when I first got warned for double checking. I never quite understood the keyword "volatile". Now, when reading it again, I see some light glimmering.
    But your proposal has some strange elements.
    First, both the singleton field as well as accessor method are always static
    --why did you make them instance based in your code?
    In order to call them, you already need an instance which defeats the purpose!
    Are you sure about that choice?Yes, that is deliberately. The intended use is to define a static instance of SingletonReference in a class that needs to be instantiated as a singleton. That reference is then used to obtain the singleton.
    Assuming that leaving out static on those was a typo,
    the only innovation in your proposal is the claim that
    "Executing an instance method on the new singleton prevents inlining".
    Where did you get that idea from?
    Its news to me. Instance methods often get inlined, not just static methods.The non static field is not a typo, but intentional. What you call a "innovation", my assumption that I prevented inlining, is exactly what I was not very sure about. I can't imagine how an interpreter or JIT compiler would navigate around that construct, but nevertheless, I am not sure. Your remark suggests that it is unsafe and I will reconsider my code (change it).
    The reason why most double checked locking solutions fail,
    including I believe yours,
    is due to completely unintuitive behavior of optimizing java runtime compilers;
    things can happen in different time order than you expect if you do not use some sort of locking.
    Specifically, typical double checked locking fails because there is no lock on the singleton,
    which means that writes to it can occur in strange order,
    which means that your null-check on it may not prevent multiple instances from being created. Yes, you convinced me.
    Thank you so much for looking into it
    Piet

  • HashMap String, ConcurrentHashMap Long, Bool concurrency , out of memory

    Need a cache as hashmap<String,ConcurrentHashMap<Long, Boolean>> for 500,000 String keys,
    each with ConcurrentHashMap of max size - million for bulk deletes (based on string key), statistics and concurrency??
    where total record count of all concurrentHashMaps is about 20 million.
    As the application is multi threaded, and we want fastest insert, update, and delete cache the only choice was a concurrentHashMap.
    Methods such as put, putIfAbsent, delete are exposed for this cache.
    For example, Is the following thread safe?
    cache = new HashMap<String, ConcurrentHashMap<Long, Boolean>>
    put(T key, value){
    ConcurrentHashMap map;
    if((map = getConcurrentHashMap(key.getStringValue())) != null){
         synchronized(cache){
              map = new ConcurrentHashMap<Long, Boolean>();
              cache.put(key.getStringValue()), map);
    map.put(key.getLongValue(), false)
    Even before we loaded a million records, we ran out of space. Why do we have so many, about 16 times the number of concurrent hash maps in heap and this is a bad sign, what other options do we have?
    12355048     593042304.00     565.5692     java.util.concurrent.locks.ReentrantLock$NonfairSync
    12355026     593041248.00     565.5682     java.util.concurrent.ConcurrentHashMap$Segment
    12355026     396169112.00     377.8163     [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
    772191     55597752     53.02215     java.util.concurrent.ConcurrentHashMap
    Thanks
    Krishna

    jtahlborn wrote:
    803891 wrote:
    :), could you read again please.
    Ofcourse, I do use putIfAbsent, but as there are many concurrent hashmaps, the only time I use synchronized is when I do not find a key without an initialized concurrentHashMap.i did read your post the first time, and it is still incorrect. the point of ConcurrentHashMap is to avoid using synchronized. besides that, your code has a timing hole if more than one thread try to access a new key for the first time. they could get 2 different sub-maps. (not to mention a logic bug). the correct way to lazy-load a ConcurrentMap (assuming that object construction for the values is cheap):
    ConcurrentHashMap<Long, Boolean> map;
    if((map = getConcurrentHashMap(key.getStringValue())) == null) {
    map = new ConcurrentHashMap<Long, Boolean>();
    ConcurrentHashMap<Long, Boolean> curMap = cache.putIfAbsebent(key.getStringValue()), map);
    if(curMap != null) {
    map = curMap;
    The good thing about my cache is 99% of the keys (String) are eagerly known. The cache is a HashMap here, so are you suggesting this should also be a ConcurrentHashMap as well, otherwise your cache.putIfAbsent will still require a lock on cache itself, which is what I did below, is there anything wrong here:
    public Boolean put(T key){
              String stringKey = key.getStringKey();
              return getLongCache(stringKey).put(key.getLongKey, true);
    all ... methods use getLongCache() first
    private ConcurrentHashMap<Long, Boolean> getLongCache(
                   String stringKey) {
              ConcurrentHashMap<Long, Boolean> longCache;
              if((longCache = cache.get(key.getStringValue())) == null) {
                   longCache = putIfAbsentLongCache(key.getStringKey);
              return longCache;
    public ConcurrentHashMap<Long, Boolean> putIfAbsentLongCache(
                   String stringKey){
              // acquire implicit client side lock as it is different from this lock
              synchronized(cache) {
                   ConcurrentHashMap<Long, Boolean> longCache;
                   if((longCache = cache.get(stringKey)) == null) {
                        longCache = new ConcurrentHashMap<Long, Boolean>();
                        cache.put(stringKey, longCache);
                   return longCache;
         }>
    No, the whole idea was to avoid the database and use it as a cache, what other alternatives do I have.i understand that. hope you are using a 64bit jvm on a box with lots o' memory. however, for most normal database scenarios, a good ORM (like hibernate) with the correct caching configured will handle the load you need. you would only need something like this for an extreme scenario, in which case you'll probably need a big box.Yeah, I did not really expect this, that is way too much memory to just setup about half a million concurrentHashMaps. But are there other choices such as writing my own map type?
    Edited by: 803891 on Oct 21, 2010 8:24 AM

  • A question about concurrency and static getter methods

    Hello
    I have a class with some static methods. they just return a reference and doesnt apply any changes.
    something like this:
    public class FieldMapper {
            private static Map<Class,Map<String,String>> fieldMap = new HashMap<Class,Map<String,String>>();
            public static getFields(Class clazz){
                  return fieldMap.get(clazz);
    }my question is, let's consider many users connect to my server and each has its own session, now assume one user want to use FieldMapper.getFields(User.class) and another is going to call FieldMapper.getFields(Employee.class) at same time or a bit milli seconds after, and this method is not synchronized, is there any conflict in calling the method? would this method return wrong reference to the first invocation?
    in genereal, may the concurrency make problem on reading resources? or just on changing resources?
    Thank you very much in advance.

    To publish an object safely, both the reference to the object and the object's state must be made visible to other threads at the same time. A properly constructed object can be safely published by:
    Initializing an object reference from a static initializer;
    Storing a reference to it into a volatile field or AtomicReference;
    Storing a reference to it into a final field of a properly constructed object; or
    Storing a reference to it into a field that is properly guarded by a lock. The internal synchronization in thread-safe collections means that placing an object in a thread-safe collection, such as a Vector or synchronizedList, fulfills the last of these requirements. If thread A places object X in a thread-safe collection and thread B subsequently retrieves it, B is guaranteed to see the state of X as A left it, even though the application code that hands X off in this manner has no explicit synchronization.
    Now in the case you have specified you are using HashMap. Which is not designed to be threadsafe as opposed to HashTable or concurrentHashMap. In such a case I would advise against using this. The concurrency problem is caused by race conditions on mutable objects, whether it is reading or writing. If it is mutable, it is susceptible to race conditions. IMHO
    &spades;

  • Should I use a static method or an instance method?

    Just a simple function to look at a HashMap and tell how many non-null entries.
    This will be common code that will run on a multi-threaded weblogic app server and potentially serve many apps running at once.
    Does this have to be an instance method? Or is it perfectly fine to use a static method?
    public static int countNonNullEntries(HashMap hm){
    if(hm==null)return 0;
    int count=0;
    for(int i=0; i<hm.size(); i++) {
    if(hm.get(i)!=null)
    { count++;}
    return count;
    OR
    public int countNonNullEntries(HashMap hm){
    if(hm==null)return 0;
    int count=0;
    for(int i=0; i<hm.size(); i++) {
    if(hm.get(i)!=null)
    { count++;}
    return count;
    }

    TPD Opitz-Consulting com wrote:
    The question is the other way around: Is there a good reason to make the method static?
    Ususally the answer is: no.The question is: does this method need state? Yes -> method of a class with that state. No -> static.
    The good thing of having this method statig is that it meight decrese memory foot pring but unless you're facing memory related problem you should not think about that.I doubt there is any difference between the memory foot print of a static or not method.
    I'm not shure if this method beeing static maks problems in multithreaded environments like the one you're aiming at. But I do know that an immutable object is always thread save.Does the method use shared state (data)? No -> no multi threaded problems.
    Can the parameters be modified by different threads? Yes, if multiple threads modified the parameter map, but nothing you can do about it here (no way to force the calling thread to lock on whatever you lock on).
    So my answer to your question is: yes, it should be non static.The method should be static since it uses no state.
    It is thread-safe when only the calling thread can modify the passed map (using a synchronized or ConcurrentHashMap is not enough, since you don't call a single atomic method on the map).
    // Better use Map instead of HashMap
    // We don't care about the generic type, but that does not mean we should use a raw type
    public static int countNonNullEntries(Map<?, ?> map) {
      // whether to accept null map or not, no need for explicit exception
      // since next statement throw NPE anyway
      Collection<?> values = map.values();
      // note your method is called countNonNull, not countNull!
      // (original code it would need to by if(null != mapValue) notNullsCounter++;
      return values.size() - java.util.Collections.frequency(values, null);
    }

  • Java.util.concurrent.ConcurrentHashMap

    All,
    I prefer to use the java.util.ConcurrentHashMap over a Hashtable but there are some points regarding this structure that are not very clear to me.
    From java.util.concurrent: Class ConcurrentHashMap:
    "A hash table supporting full concurrency of retrievals and adjustable expected concurrency for updates. This class obeys the same functional specification as Hashtable, and includes versions of methods corresponding to each method of Hashtable.
    *+However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access. This class is fully interoperable with Hashtable in programs that rely on its thread safety but not on its synchronization details. Iterators are designed to be used by only one thread at a time."+ *
    Also from: Java API: Package java.util.concurrent, we read:
    "The "Concurrent" prefix used with some classes in this package is a shorthand indicating several differences from similar "synchronized" classes. For example java.util.Hashtable and Collections.synchronizedMap(new HashMap()) are synchronized. But ConcurrentHashMap is "concurrent". A concurrent collection is thread-safe, but not governed by a single exclusion lock. In the particular case of ConcurrentHashMap, it safely permits any number of concurrent reads as well as a tunable number of concurrent writes. "Synchronized" classes can be useful when you need to prevent all access to a collection via a single lock, at the expense of poorer scalability. In other cases in which multiple threads are expected to access a common collection, "concurrent" versions are normally preferable. And unsynchronized collections are preferable when either collections are unshared, or are accessible only when holding other locks."
    Based on above, is this correct of I say:
    When using a structure like Hashtable, all the methods or operations are synchronized,
    meaning if one thread is accessing the Hashtable (by get(), put(),... or other methods on this structure), it owns the lock and all other threads will lock out until the thread that owns the lock releases the lock; which means only one thread can access the hash table at a time; which can cause performance issues.
    We need to use a synchronized block or method only of two threads modify a "shared resource", if they do not modify a shared resource, we do not need to use the synchronization.
    On the other hand, the methods of ConcurrentHashMap are not synchronized; so multiple threads can access the ConcurrentHashMap at the same time. But isn't the ConcurrentHashMap itself the "shared resource" that threads are accessing? Should we use it only if the threads are reading from map and not writing to it? And then if threads also write to the structure, then it looks like its better to not to use the ConcurrentHashMap, rather use the regular HashMap with the synchronized wrapper?
    Any help is greatly appreciated.

    We need to use a synchronized block or method only of two threads modify a "shared resource", if they do not modify a shared resource, we do not need to use the synchronization. Actually, you need to synchronize access to the shared resource for both readers and writers. If one thread is updating an unsynchronized HashMap, and a concurrent thread tries to read that map, it may be in an inconsistent state. When synchronizing on the map, the reader will be blocked until the writer completes.
    What you don't need to do is prevent multiple readers from accessing the map, if there's no writer. However, a synchronized map or HashTable will single-thread reads as well as writes.
    On the other hand, the methods of ConcurrentHashMap are not synchronized; so multiple threads can access the ConcurrentHashMap at the same time. But isn't the ConcurrentHashMap itself the "shared resource" that threads are accessing? No, it's actually synchronized at a finer level. Without getting into the details of HashMap implementation, an object's hashcode is used to identify a linked list of hashmap entries. The only time that you have a concurrency issue is when a reader and writer are accessing the same list. So the ConcurrentHashMap locks only the list that's being updated, and allows readers (and writers!) to access the other bucket lists. Plus, it allows two readers to proceed concurrently.

  • ConcurrentHashMap VS. HashTable

    Hi all,
    I need to use a thread-safe map and am not sure if I can safely use java.util.concurrent.ConcurrentHashMap instead of HashTable w/o external synchronization. The Java docs says:
    "A hash table supporting full concurrency of retrievals and adjustable expected concurrency for updates. This class obeys the same functional specification as Hashtable, and includes versions of methods corresponding to each method of Hashtable.
    *+However, even though all operations are thread-safe, retrieval operations do+ +not+ +entail locking, and there is+ +not+ +any support for locking the entire table in a way that prevents all access. This class is fully interoperable with+ **+Hashtable+** +in programs that rely on its thread safety but not on its synchronization details.+*
    *+Retrieval operations (including+ **+get+**+) generally do not block, so may overlap with update operations (including+ **+put+** +and+ **+remove+**+). Retrievals reflect the results of the most recently+ +completed+ +update operations holding upon their onset. For aggregate operations such as+ **+putAll+** +and+ **+clear+**+, concurrent retrievals may reflect insertion or removal of only some entries. Similarly, Iterators and Enumerations return elements reflecting the state of the hash table at some point at or since the creation of the iterator/enumeration+*.
    They do +not+ throw [ConcurrentModificationException|http://java.sun.com/javase/6/docs/api/java/util/ConcurrentModificationExceptio
    *+However, iterators are designed to be used by only one thread at a time.+*"
    I do use iterators on my map; and it will be used by many threads at the same time; so does that mean I need to externally "synchronize" my map?
    The parts in bold and italic made me not sure about using the ConcurrentHashMap...

    JavaFunda wrote:
    So can anybody give a example where we hashtable can not be replace by ConcusrrentHashMapPersonally, other than Peter's first suggestion, I can't think of a single one. I believe that EJP's post (other than line 3) was aimed at why you might prefer a HashMap ( not Hashtable) over CHM; and he's dead right.
    Winston

  • ConcurrentHashMap keySet(), entrySet(), values() thread-safety?

    hi all,
    just wondering why this code is valid? (Taken from java.util.concurrent.ConcurrentHashMap in jdk1.6.0_07):
    transient Set<K> keySet;
    transient Set<Map.Entry<K,V>> entrySet;
    transient Collection<V> values;and further down:
    public Set<K> keySet() {
        Set<K> ks = keySet;
        return (ks != null) ? ks : (keySet = new KeySet());
    public Collection<V> values() {
        Collection<V> vs = values;
        return (vs != null) ? vs : (values = new Values());
    public Set<Map.Entry<K,V>> entrySet() {
        Set<Map.Entry<K,V>> es = entrySet;
        return (es != null) ? es : (entrySet = new EntrySet());
    }Isn't there the risk of another thread reading a partially initialized keySet?

    Basically, the only state in the internal classes is their 'final' implicit reference to the parent map, and the new JMM guarantees that final fields will have correct visibility across multiple threads if the constructor is 'correctly' implemented, ie another thread that can see the constructed object will see the 'correct' values of any final fields of that object.
    I'm not quite sure you deduced this correctly from what the memory model says about final variables. It seems to me you initial hunch was actually correct -
    there is a chance of getting an improperly constructed objected when calling keySet(), values() or entrySet():
    Thread A accesses keySet(), and the compiler decides to do the assignment to the member "keySet" before it invokes the constructor.
    Now, if Thread B enters the method, it will return a reference to the partially constructed inner class object that it may try to use. You are right: there is only one implicitly final member. But where is it stated that this member is initialized up-front?
    Please look at the following excerpt from the Java language spec, in particular sentence 3. Nowhere does it say that objects containing final fields are treated any differently by the compiler with regards to re-ordering of instructions:
    "The usage model for final fields is a simple one. Set the final fields for an object in that object's constructor. Do not write a reference to the object being constructed in a place where another thread can see it before the object's constructor is finished. If this is followed, then when the object is seen by another thread, that thread will always see the correctly constructed version of that object's final fields. It will also see versions of any object or array referenced by those final fields that are at least as up-to-date as the final fields are."

  • Removing objects from a concurrentHashMap

    Hi there,
    I am trying to remove an object added to the map. But, after I remove the object using remove(key, value) the object seems to be still in the map. I am using the following functions. Please help.
      ConcurrentMap m_RequestQueue = new ConcurrentHashMap<String, QueueData>();
    public void addToRequestQueue(String id, QueueData data) throws ProvisionException
            if (isProvisionIdExist(id))
                if (null != id)
                    m_RequestQueue.putIfAbsent(id, data);
                else
                // log
            else
                throw new ProvisionException("Invalid ProvisonId or ProvisionId already exists");
    public void removeFromRequestQueue(String provId)
            if ((null != provId) && isProvisionIdExist(provId))
                QueueData data;
                if( ( data = (QueueData)m_RequestQueue.get(provId)) != null) {
                    m_RequestQueue.remove(provId, data);
    public boolean isProvisionIdExist(String provId)
            boolean retValue = false;
            if (m_RequestQueue.containsKey(provId))
                retValue = true;
            return retValue;
        }

    Oh, sorry! my bad.
    The problem is in the following function. The check should have been if (!isProvisionIdExist(id)) instead of
    if (isProvisionIdExist(id))
    public void addToRequestQueue(String id, QueueData data) throws ProvisionException
            if (!isProvisionIdExist(id))
                if (null != id)
                    m_RequestQueue.putIfAbsent(id, data);
                else
                // log
            else
                throw new ProvisionException("Invalid ProvisonId or ProvisionId already exists");
        }

  • Thoughts on adding ConcurrentMap methods to StoredMap?

    as far as i can tell, StoredMap has the potential to implement the extra methods in the jdk 1.5 ConcurrentMap interface. Database already has a putNoOverwrite method which would be the implementation of putIfAbsent. Personally, however, i am more interested in the other methods, all of which basically do their work only if the current value matches a given old value. this enables safe concurrent updates to a StoredMap even outside of transactions, basically using an optimistic scenario:
    - read existing key,value (hold no locks)
    - copy current value and modify the copy
    - write modified value only if current value matches what is now in the database (this line within the context of a RMW lock)
    any idea if this could be incorporated in the je codebase anytime soon? i may end up implementing it in our codebase, although the je api is not easy to extend as most classes/useful methods are package protected (arg!).

    hey,
    just wanted to follow up on this a little. after using the concurrent implementation for a while (with transactions enabled), i experimented with extending the api to add a "transaction-like" extension to the concurrentmap api. this basically blends the concurrentmap api with the option of better performance when transactions are enabled in the underlying bdb. there are three methods added, which basically allow for "locking" a given key and "committing" or "rolling back" the updates as appropriate (if transactions are not enabled, the new methods are largely no-ops, and you get normal concurrent map behavior). thought i'd post the new code in case you were interested in providing this facility to other users (or, you could just stick with the original version posted above).
    Example usage:
    Object key;
    try {
      Object value = map.getForUpdate(key);
      // ... run concurrent ops on value ...
      map.replace(key, value, newValue);
      map.completeUpdate(key);
    } finally {
      map.closeUpdate(key);
    }New implementation:
    public class StoredConcurrentMap extends StoredMap
      private final ThreadLocal<UpdateState> _updateState =
        new ThreadLocal<UpdateState>();
      public StoredConcurrentMap(
          Database database, EntryBinding keyBinding,
          EntryBinding valueEntityBinding, boolean writeAllowed)
        super(database, keyBinding, valueEntityBinding, writeAllowed);
      public Object getForUpdate(Object key)
        if(_updateState.get() != null) {
          throw new IllegalStateException(
              "previous update still outstanding for key " +
              _updateState.get()._key);
        UpdateState updateState = new UpdateState(key, beginAutoCommit());
        _updateState.set(updateState);
        DataCursor cursor = null;
        Object value = null;
        try {
          cursor = new DataCursor(view, true, key);
          if(OperationStatus.SUCCESS == cursor.getNextNoDup(true)) {
            // takeover ownership of the cursor
            value = updateState.loadCurrentValue(cursor);
            cursor = null;
          closeCursor(cursor);
        } catch (Exception e) {
          closeCursor(cursor);
          throw handleException(e, false);
        return value;
      public void completeUpdate(Object key)
        UpdateState updateState = getUpdateState(key);
        if(updateState != null) {
          try {
            updateState.clearCurrentValue(this);
            commitAutoCommit(updateState._doAutoCommit);
            // only clear the reference if everything succeeds
            _updateState.set(null);
          } catch(DatabaseException e) {
            throw new RuntimeExceptionWrapper(e);
      public void closeUpdate(Object key)
        UpdateState updateState = getUpdateState(key);
        if(updateState != null) {
          // this op failed, abort (clear the reference regardless of what happens
          // below)
          _updateState.set(null);
          try {
            updateState.clearCurrentValue(this);
            view.getCurrentTxn().abortTransaction();
          } catch(DatabaseException ignored) {
      public Object putIfAbsent(Object key, Object value)
        UpdateState updateState = getUpdateState(key);
        if(valueExists(updateState)) {
          return updateState._curValue;
        Object oldValue = null;
        DataCursor cursor = null;
        boolean doAutoCommit = beginAutoCommit();
        try {
          cursor = new DataCursor(view, true);
          while(true) {
            if(OperationStatus.SUCCESS ==
               cursor.putNoOverwrite(key, value, false)) {
              // we succeeded
              break;
            } else if(OperationStatus.SUCCESS ==
                      cursor.getSearchKey(key, null, false)) {
              // someone else beat us to it
              oldValue = cursor.getCurrentValue();
              break;
            // we couldn't put and we couldn't get, try again
          closeCursor(cursor);
          commitAutoCommit(doAutoCommit);
        } catch (Exception e) {
          closeCursor(cursor);
          throw handleException(e, doAutoCommit);
        return oldValue;
      public boolean remove(Object key, Object value)
        UpdateState updateState = getUpdateState(key);
        if(valueExists(updateState)) {
          if(ObjectUtils.equals(updateState._curValue, value)) {
            try {
              updateState._cursor.delete();
              updateState.clearCurrentValue(this);
              return true;
            } catch (Exception e) {
              throw handleException(e, false);
          } else {
            return false;
        boolean removed = false;
        DataCursor cursor = null;
        boolean doAutoCommit = beginAutoCommit();
        try {
          cursor = new DataCursor(view, true, key);
          if(OperationStatus.SUCCESS == cursor.getNextNoDup(true)) {
            Object curValue = cursor.getCurrentValue();
            if(ObjectUtils.equals(curValue, value)) {
              cursor.delete();
              removed = true;
          closeCursor(cursor);
          commitAutoCommit(doAutoCommit);
        } catch (Exception e) {
          closeCursor(cursor);
          throw handleException(e, doAutoCommit);
        return removed;
      public boolean replace(Object key, Object oldValue, Object newValue)
        UpdateState updateState = getUpdateState(key);
        if(valueExists(updateState)) {
          if(ObjectUtils.equals(updateState._curValue, oldValue)) {
            try {
              updateState.replaceCurrentValue(newValue);
              return true;
            } catch (Exception e) {
              throw handleException(e, false);
          } else {
            return false;
        boolean replaced = false;
        DataCursor cursor = null;
        boolean doAutoCommit = beginAutoCommit();
        try {
          cursor = new DataCursor(view, true, key);
          if(OperationStatus.SUCCESS == cursor.getNextNoDup(true)) {
            Object curValue = cursor.getCurrentValue();
            if(ObjectUtils.equals(curValue, oldValue)) {
              cursor.putCurrent(newValue);
              replaced = true;
          closeCursor(cursor);
          commitAutoCommit(doAutoCommit);
        } catch (Exception e) {
          closeCursor(cursor);
          throw handleException(e, doAutoCommit);
        return replaced;
      public Object replace(Object key, Object value)
        UpdateState updateState = getUpdateState(key);
        if(valueExists(updateState)) {
          try {
            return updateState.replaceCurrentValue(value);
          } catch (Exception e) {
            throw handleException(e, false);
        Object curValue = null;
        DataCursor cursor = null;
        boolean doAutoCommit = beginAutoCommit();
        try {
          cursor = new DataCursor(view, true, key);
          if(OperationStatus.SUCCESS == cursor.getNextNoDup(true)) {
            curValue = cursor.getCurrentValue();
            cursor.putCurrent(value);
          closeCursor(cursor);
          commitAutoCommit(doAutoCommit);
        } catch (Exception e) {
          closeCursor(cursor);
          throw handleException(e, doAutoCommit);
        return curValue;
       * @return the current UpdateState for the given key, if any, {@code null}
       *         otherwise.
      private UpdateState getUpdateState(Object key)
        UpdateState updateState = _updateState.get();
        if((updateState != null) && (ObjectUtils.equals(updateState._key, key))) {
          return updateState;
        return null;
       * @return {@code true} if the update state exists and found a value (which
       *         is currently locked)
      private boolean valueExists(UpdateState updateState)
        return((updateState != null) && (updateState._cursor != null));
       * Maintains state about an object loaded in a
       * {@link StoredConcurrentMap#getForUpdate} call.
      private static class UpdateState
        public final Object _key;
        public final boolean _doAutoCommit;
        public DataCursor _cursor;
        public Object _curValue;
        private UpdateState(Object key, boolean doAutoCommit) {
          _key = key;
          _doAutoCommit = doAutoCommit;
         * Loads the current value from the given cursor, and maintains a
         * reference to the given cursor and the loaded value.
        public Object loadCurrentValue(DataCursor cursor)
          throws DatabaseException
          _cursor = cursor;
          _curValue = _cursor.getCurrentValue();
          return _curValue;
         * Replaces the current value in the current cursor with the given value.
         * @return the old value
        public Object replaceCurrentValue(Object newValue)
          throws DatabaseException
          Object oldValue = _curValue;
          _cursor.putCurrent(newValue);
          _curValue = newValue;
          return oldValue;
         * Closes the current curstor and clears the references to the cursor and
         * current value.
        public void clearCurrentValue(StoredConcurrentMap map) {
          try {
            map.closeCursor(_cursor);
          } finally {
            _cursor = null;
            _curValue = null;
    }

  • ConcurrentMap.putIfAbsent sucks

    After using ConcurrentMap for a while I have come to the conclusion that putIfAbsent is rather inconvenient.
    Problem #1:
    When there is already a value in the map, it returns that value. But when there isn't, it returns null instead of returning the value you passed in.
    So instead of being able to write this:
    Value v = map.putIfAbsent(k, new Value());You end up having to write this:
    Value nv = new Value();
    Value v = map.putIfAbsent(k, nv);
    if (v == null) {
        v = nv;
    Problem #2:
    Sometimes "new Value()" can take a very long time, yet we have to construct it up-front. This makes ConcurrentHashMap useless as a basis for implementing caches, where the entire idea is to avoid having to create the object in the first place. What I would rather be able to do is this:
    Value v = map.putIfAbsent(k, new Factory<Value>() {
        public Value createValue() {
            return new Value();
    });What's really awesome about this is that the ConcurrentHashMap class doesn't even expose a mechanism for a subclass to lock the map, so you have to jump through some real hoops to get it to do what you want.

    For the 0.01% of applications which do need to store nulls and distinguish this from a nonexistent element, they can define a Null class. Punishing the other 99.99% of developers to benefit the rest has never been a good justification.
    As for the lock, I didn't mean so much to lock the entire map, but locking the factory which generates the object is probably adequate.
    In any case I can do what I want with copious wrappers around Sun's utilities... it's just that the things we're wrapping for exist at least a dozen times in our application, so I imagine it would be useful for everybody.
    The utility classes I'm currently writing, for instance:
    1. A lazy value initialiser which uses a double-locking pattern (and thus will only work on Java 5 or later) so that multiple threads trying to initialise a single value will properly cooperate.
    2. A cache which uses a ConcurrentMap<K,LazyValue<V>> and the poorly designed putIfAbsent, wrapping it all up so that it's actually usable without having to write the maximum amount of code.

  • LRU concurrenthashmap

    Hi,
    I have a requirement to implement LRU cache strategy using concurrenthashmap.
    Is there already an implementation in oracle.javatools.* related to this?
    I cannot use open source implementations so anything related to JDk will be really helpful.
    Thanks
    Chiranjib

    nope, there is nothing like this in the jdk currently (assuming you specifically mean the ConcurrentMap). there is a non-synchronized LRU map in LinkedHashMap. you could use it to create a synchronized Map which exposes ConcurrentMap methods. however, it won't have the concurrent performance characteristics of something like ConcurrentHashMap.

  • Error while calling a method on Bean (EJB 3.0)

    I am getting an error while calling a method on EJB. I am using EJB3.0 and my bean is getting properly deployed(i am sure b'cos i can see the successfullly deployed message). Can any body help me
    Error is -->
    Error while destroying resource :An I/O error has occured while flushing the output - Exception: java.io.IOException: An established connection was aborted by the software in your host machine
    Stack Trace:
    java.io.IOException: An established connection was aborted by the software in your host machine
    at sun.nio.ch.SocketDispatcher.write0(Native Method)
    at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:33)
    at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
    at sun.nio.ch.IOUtil.write(IOUtil.java:75)
    at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:302)
    at com.sun.enterprise.server.ss.provider.ASOutputStream.write(ASOutputStream.java:138)
    at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
    at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
    at org.postgresql.PG_Stream.flush(PG_Stream.java:352)
    at org.postgresql.core.QueryExecutor.sendQuery(QueryExecutor.java:159)
    at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:70)
    at org.postgresql.jdbc1.AbstractJdbc1Connection.ExecSQL(AbstractJdbc1Connection.java:482)
    at org.postgresql.jdbc1.AbstractJdbc1Connection.ExecSQL(AbstractJdbc1Connection.java:461)
    at org.postgresql.jdbc1.AbstractJdbc1Connection.rollback(AbstractJdbc1Connection.java:1031)
    at org.postgresql.jdbc2.optional.PooledConnectionImpl$ConnectionHandler.invoke(PooledConnectionImpl.java:223)
    at $Proxy34.close(Unknown Source)
    at com.sun.gjc.spi.ManagedConnection.destroy(ManagedConnection.java:274)
    at com.sun.enterprise.resource.LocalTxConnectorAllocator.destroyResource(LocalTxConnectorAllocator.java:103)
    at com.sun.enterprise.resource.AbstractResourcePool.destroyResource(AbstractResourcePool.java:603)
    at com.sun.enterprise.resource.AbstractResourcePool.resourceErrorOccurred(AbstractResourcePool.java:713)
    at com.sun.enterprise.resource.PoolManagerImpl.putbackResourceToPool(PoolManagerImpl.java:424)
    at com.sun.enterprise.resource.PoolManagerImpl.resourceClosed(PoolManagerImpl.java:393)
    at com.sun.enterprise.resource.LocalTxConnectionEventListener.connectionClosed(LocalTxConnectionEventListener.java:69)
    at com.sun.gjc.spi.ManagedConnection.connectionClosed(ManagedConnection.java:618)
    at com.sun.gjc.spi.ConnectionHolder.close(ConnectionHolder.java:163)
    at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.closeDatasourceConnection(DatabaseAccessor.java:379)
    at oracle.toplink.essentials.internal.databaseaccess.DatasourceAccessor.closeConnection(DatasourceAccessor.java:367)
    at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.closeConnection(DatabaseAccessor.java:402)
    at oracle.toplink.essentials.internal.databaseaccess.DatasourceAccessor.afterJTSTransaction(DatasourceAccessor.java:100)
    at oracle.toplink.essentials.threetier.ClientSession.afterTransaction(ClientSession.java:104)
    at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.afterTransaction(UnitOfWorkImpl.java:1816)
    at oracle.toplink.essentials.transaction.AbstractSynchronizationListener.afterCompletion(AbstractSynchronizationListener.java:161)
    at oracle.toplink.essentials.transaction.JTASynchronizationListener.afterCompletion(JTASynchronizationListener.java:87)
    at com.sun.ejb.containers.ContainerSynchronization.afterCompletion(ContainerSynchronization.java:174)
    at com.sun.enterprise.distributedtx.J2EETransaction.commit(J2EETransaction.java:467)
    at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:357)
    at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3653)
    at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3431)
    at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1247)
    at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:197)
    at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:110)
    at $Proxy84.addDepartment(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:121)
    at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:650)
    at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:193)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1705)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1565)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:947)
    at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:178)
    at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:717)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:473)
    at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1270)
    at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:479)
    End of Stack Trace
    |#]
    RAR5035:Unexpected exception while destroying resource. To get exception stack, please change log level to FINE.
    EJB5018: An exception was thrown during an ejb invocation on [DepartmentSessionBean]
    javax.ejb.EJBException: Unable to complete container-managed transaction.; nested exception is: javax.transaction.SystemException
    javax.transaction.SystemException
    at com.sun.enterprise.distributedtx.J2EETransaction.commit(J2EETransaction.java:452)
    at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:357)
    at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3653)
    at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3431)
    at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1247)
    at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:197)
    at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:110)
    at $Proxy84.addDepartment(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    Means theres an error in XML/ABAP conversion probably due a syntax error...
    Regards
    Juan

Maybe you are looking for