static的常驻内存

对于配置等经常使用的对象,而且基本上在使用的时候很少修改的,我们可以让它常驻内存.

如何常驻内存,这是我们最关心的.这就是static的使用技巧,
照例以配置文件来讨论,请看以下代码

class Config{

private static HashMap expMap = new HashMap();

//装载personMap,为简单不使用singleton模式
public Config(){
   //读取配置文件,并装载进expMap
   loadExpMap();
}

public static Object getExpMap(String key){
   synchronized(this){
       return expMap.get(key);
     }
}

public static HashMap setExpMap(String key, Object o){
   synchronized(this){
       expMap.put(key, o);
     }
   return expMap.clone();
}

public static Object removeExpMap(String key){
   synchronized(this){
       expMap.remove(key);
     }
   return expMap.clone();
}

}

注意以下２点
所有的调用方法如果不是确定已经被同步,误必使用synchronized,当然,你说用rw锁也行^^
如果需要返回,为其他线成或者其他此对象消费者着想,　请clone,



顺带说下,关于JNDL之类的动态装载工厂方法是如何实现的.
JNDI的动态装载方式在ResourcesManager类中，使用的是类似我这样的static常驻内存方式，不过他使用的是WeakHashMap做的引用，　也就是说当不使用这些工厂对象时候，里面的引用对象会被自动回收

不要轻易用它!!太高级了,贵啊,一般情况我们用不起^^,　它会对每个加入其中的对象产生线成去检测回收的


回各位大大的话
1为什么需要同步,涉及到多线城同步是必须的,只是看你的使用方式问题而已, 比如有位仁兄说性能消耗太高,这不是问题的问题.  如果不是static, 比如说cache 然后类似使用servlet装载进app做全局的话, 也有点这个的意思, 当然,这个时候由于可能读写巨大,所以就只能尽量使用rw锁了,性能上优化点.
2为什么clone,既然是一个公共对象,你把引用的值返回出去你放心??可能会被外面的资源通过这个引用修改它的，所以不要直接返回.
3这是个简单的全局对象的例子,到底里面是什么无所谓,所以不存在什么set get的问题

写了４篇　　真佩服自己这么能耐住性子^^,　改天写另外池化　比较麻烦

return expMap.clone()和return expMap 在性能上有什么区别？
能否详解？

n台机器怎么同步?

# private static HashMap expMap = new HashMap(); 

你为什么不使用private static Map expMap = new ConcurrentHashMap();
这样不是减少你同步的问题，性能也好些吗?

才看到你的HashMap的定义都没有使用接口哦


n台机器的话建议你做个memcahced集中管理吧，本地存一份，memcahced也有一份，更新的同时更新memcahced。获取的时候先找本地的，没有的话在去memcahced中找

真正常驻内存又常用的东西不要用map！直接定义到类里。

另外，不要修改了再clone，这是个坏习惯，宁愿clone了再修改！！无必要的话，根本不要去clone.

synchronized一定不能滥用。这东西是典型的性能杀手。根据场景选择合适的同步方式才是必要的。

这种配置信息本来就是键值对的方式的，为什么MAP不合适？多吃你1K内存，还是耗费的起的。

修改了再clone有什么问题呢？人家那个方法是要讲一个值put进map去，然后还要把这个map返回。
之所以返回一个clone的，是因为如果直接返回原map的引用，外界就有可能修改了这个公共配置map里的对象。
先clone了再修改，那不是要把两个都修改一遍吗？有什么好的？看看clone的实现吧，有那么恐怖吗？


synchronized是不能滥用，可是楼主的文章里没有滥用，你在下边说这个东西是性能杀手，是暗含着楼主的用法是滥用吗？如果不是的话，那么synchronized滥用的危害是另一个话题，又为什么拿到这篇帖子下边来说？

synchronized里的代码块执行的仅仅是个get或是put到map里去，还是不会有什么大问题的吧。

总之看到你的回复，觉得很不舒服。

没有大问题是因为你没碰到过真正这东西形成的性能瓶颈。。当然大部分情况下你爱怎么写怎么写，企业应用或许全部synchronized也没人理你。。

哦？我语气比较生硬，听着不舒服？？

1.这种配置信息本来就是键值对的方式的，为什么MAP不合适？多吃你1K内存，还是耗费的起的。
如果耗费的起，那也用不着谈什么性能了，这里说map不合适不是内存上的，而是查找时间上的。想必你应该知道查询和直接索引的速度区别吧！

2.修改了再clone有什么问题呢？人家那个方法是要讲一个值put进map去，然后还要把这个map返回。
之所以返回一个clone的，是因为如果直接返回原map的引用，外界就有可能修改了这个公共配置map里的对象。
先clone了再修改，那不是要把两个都修改一遍吗？有什么好的？看看clone的实现吧，有那么恐怖吗？

为什么不要修改了再clone,因为这样就使内存中存在了2个功能完全相同的副本。而其中一个无用。这样的使用方式只在很少的情景下才需要出现。我很奇怪的是为什么要对外返回一个内部对象的副本而不是提供一个查询内部对象的方法？


3.synchronized是不能滥用，可是楼主的文章里没有滥用，你在下边说这个东西是性能杀手，是暗含着楼主的用法是滥用吗？如果不是的话，那么synchronized滥用的危害是另一个话题，又为什么拿到这篇帖子下边来说？

config一般来讲是一个读(get)多写(put)少的对象。楼主的例子在读（get）中加了synchronized，那么如果有多个线程同时读config会怎么样呢？就会被互相同步！synchronized用在这里是不合适的。


如果还有不舒服，只有请克服..

很是折腾.
已然是读配置文件.
写个方法暴漏get
把set隐藏起来就可以了
又不需要支持代码修改了,重读配置文件