1

私のアプリケーションでは、データベース内のデータ行を表すエンティティに対して、それを表すJavaオブジェクトが最大で1つあることを確認する必要があります。

コヒーレンシの問題に巻き込まれる可能性があるため、equals（）であることを確認するだけでは不十分です。つまり、基本的にマルチトンが必要です。さらに、必要がない場合はこのオブジェクトをメモリに保持する必要がないため、弱参照を使用します。

私はこの解決策を考案しました：

package com.example;

public class DbEntity {
    // a DbEntity holds a strong reference to its key, so as long as someone holds a
    // reference to it the key won't be evicted from the WeakHashMap
    private String key;

    public void setKey(String key) {
        this.key = key;
    }

    public String getKey() {
        return key;
    }

    //other stuff that makes this object actually useful.

}

package com.example;

import java.lang.ref.WeakReference;
import java.util.WeakHashMap;
import java.util.concurrent.locks.ReentrantLock;

public class WeakMultiton {

    private ReentrantLock mapLock = new ReentrantLock();
    private WeakHashMap<String, WeakReference<DbEntity>> entityMap = new WeakHashMap<String, WeakReference<DbEntity>>();

    private void fill(String key, DbEntity object) throws Exception {
        // do slow stuff, typically fetch data from DB and fill the object.
    }

    public DbEntity get(String key) throws Exception {
        DbEntity result = null;
        WeakReference<DbEntity> resultRef = entityMap.get(key);
        if (resultRef != null){
            result = resultRef.get();
        }
        if (result == null){
            mapLock.lock();
            try {
                resultRef = entityMap.get(key);
                if (resultRef != null){
                    result = resultRef.get();
                }
                if (result == null){
                    result = new DbEntity();                
                    synchronized (result) {
                        // A DbEntity holds a strong reference to its key, so the key won't be evicted from the map
                        // as long as result is reachable.
                        entityMap.put(key, new WeakReference<DbEntity>(result));

                        // I unlock the map, but result is still locked.
                        // Keeping the map locked while querying the DB would serialize database calls!
                        // If someone tries to get the same DbEntity the method will wait to return until I get out of this synchronized block.
                        mapLock.unlock();

                        fill(key, result);

                        // I need the key to be exactly this String, not just an equal one!!
                        result.setKey(key);
                    }
                }
                } finally {
                // I have to check since I could have already released the lock.
                if (mapLock.isHeldByCurrentThread()){
                    mapLock.unlock();
                }
            }
        }
        // I synchronize on result since some other thread could have instantiated it but still being busy initializing it.
        // A performance penality, but still better than synchronizing on the whole map.
        synchronized (result) {
            return result;
        }
    }
}

WeakMultitonは、データベースラッパー（データベースへの単一のアクセスポイント）でのみインスタンス化され、そのget（Stringキー）はもちろんDbEntityを取得する唯一の方法になります。さて、私の知る限り、これは機能するはずですが、これは私にとってかなり新しいものなので、同期や弱参照について何かを監視している可能性があるのではないかと心配しています。欠陥を見つけたり、改善を提案したりできますか？

4

1 に答える 1

1

私はグアバの MapMaker について知り、この一般的な AbstractWeakMultiton を書きました:

package com.example;

import java.util.Map;
import java.util.concurrent.locks.ReentrantLock;

import com.google.common.collect.MapMaker;

public abstract class AbstractWeakMultiton<K,V, E extends Exception> {

    private ReentrantLock mapLock = new ReentrantLock();
    private Map<K, V> entityMap = new MapMaker().concurrencyLevel(1).weakValues().<K,V>makeMap();

    protected abstract void fill(K key, V value) throws E;
    protected abstract V instantiate(K key);
    protected abstract boolean isNullObject(V value);


    public V get(K key) throws E {
        V result = null;
        result = entityMap.get(key);
        if (result == null){
            mapLock.lock();
            try {
                result = entityMap.get(key);
                if (result == null){
                    result = this.instantiate(key);             
                    synchronized (result) {
                        entityMap.put(key, result);
                        // I unlock the map, but result is still locked.
                        // Keeping the map locked while querying the DB would serialize database calls!
                        // If someone tries to get the same object the method will wait to return until I get out of this synchronized block.
                        mapLock.unlock();

                        fill(key, result);

                    }
                }
            } finally {
                // I have to check since the exception could have been thrown after I had already released the lock.
                if (mapLock.isHeldByCurrentThread()){
                    mapLock.unlock();
                }
            }
        }
        // I synchronize on result since some other thread could have instantiated it but still being busy initializing it.
        // A performance penalty, but still better than synchronizing on the whole map.
        synchronized (result) {
            // I couldn't have a null result because I needed to synchronize on it,
            // so now I check whether it's a mock object and return null in case.
            return isNullObject(result)?null:result;
        }
    }
}

以前の試みと比較して、次の利点があります。

値がキーへの強力な参照を保持しているという事実に依存しません 期限切れの弱参照の厄介な二重チェックを行う必要はありません 再利用可能です

一方、最初のソリューションはランタイム環境のクラスのみを使用していましたが、かなり強力な Guava ライブラリに依存しています。私はそれで暮らすことができます。

私は明らかに、さらなる改善とエラーの発見、そして基本的に最も重要な質問に答えるすべてのものを探しています:それは動作しますか?

于 2011-11-19T21:22:32.480 に答える