shidu

    java.lang.ref包是为了增强内存管理功能，它定义了3种引用类。根据引用强度的又强到弱依次是：SoftReference、WeakReference和PhantomReference，这些引用类介于可达对象和不可达对象之间。

    SoftReference在内存足够的时候，它们通常不被回收，当内存不够的时候，才进行回收这类内存。还能保证在Java抛出OutOfMemory 异常之前，被设置为null。它可以用于实现一些常用图片的缓存，实现Cache的功能，例如：
//申请一个图像对象
Image image=new Image();//创建Image对象
…
//使用 image
…
//使用完了image，将它设置为soft 引用类型，并且释放强引用；
SoftReference sr=new SoftReference(image);
image=null;
…
//下次使用时
if (sr!=null) {
    image=sr.get();
}
else {
    //由于GC由于低内存，已释放image，因此需要重新装载；
    image=new Image();
    sr=new SoftReference(image);
}

    Weak引用对象与Soft引用对象的最大不同就在于：GC在进行回收时，需要通过算法检查是否回收Soft引用对象，而对于Weak引用对象，GC总是进行回收。Weak引用对象更容易、更快被GC回收。虽然，GC在运行时一定回收Weak对象，但是复杂关系的Weak对象群常常需要好几次GC的运行才能完成。Weak引用对象常常用于Map结构中，引用数据量较大的对象，一旦该对象的强引用为null时，GC能够快速地回收该对象空间。

    Phantom引用的用途较少，主要用于辅助finalize函数的使用。Phantom对象指一些对象，它们执行完了finalize函数，并为不可达对象，但是它们还没有被GC回收。这种对象可以辅助finalize进行一些后期的回收工作，我们通过覆盖Reference的clear()方法，增强资源回收机制的灵活性。

    Weak引用和Phantom引用没有看到例子，不是很理解，感觉用处不是很大（SoftReference的用处就大吗？）。这些引用对象的解决方案以后到底是不是能用到还未知。

    11月这个月，我被借去做组件，其实不是做啦，是把以前的C#的翻译成Java的。天哪，要命呀，我是C#盲呀。但是这还不是最痛苦的，C#毕竟和Java有点像，看不懂的就可以胡乱猜测。最ft的是，C#代码好长好长好长，类好长好长好长，方法好长好长好长，看着巨胆寒。感觉以后的的日子会度日如年的（但愿是错觉吧）。

    不过，我是打算在这段时间好好看看“责任模式”，正在进行中，最近一直困惑的是到底用到什么程度才算比较合理。昨晚睡觉做梦都梦到了，夸张。抓紧这两天和老耿（项目的负责人，工匠）商量商量。

    刚过了金秋10月，就到了阴冷的11月，难熬的11月赶快过去吧，这样我就可以回到原来的项目组，我对“责任模式”也会有更深刻的认识，还可以收获一个月的工资，呵呵。

内容大部分是转载，觉得不错，整理一下登在此处。

BeanWrapper和BeanFactory是spring的核心，BeanWrapper实现了针对单个Bean的属性设定操作。而BeanFactory则是针对多个Bean的管理容器，根据给定的配置文件，BeanFactory从中读取类名、属性名/值，然后通过Reflection机制进行Bean加载和属性设定。

BeanWrapper的主要功能是，由Spring根据配置文件，将其他对象的引用通过组件的提供的setter方法进行设定。
1、如果借助Java的Reflection机制完成：
Class cls = Class.forName("net.xiaxin.beans.User");
Method mtd = cls.getMethod("setName",new Class[]{String.class});
Object obj = (Object)cls.newInstance();
mtd.invoke(obj,new Object[]{"Erica"});
return obj;
2、通过Spring BeanWrapper操作一个JavaBean：
Object obj = Class.forName("net.xiaxin.beans.User").newInstance();
BeanWrapper bw = new BeanWrapperImpl(obj);
bw.setPropertyValue("name", "Erica");
对比之前的代码，相信大家已经知道BeanWrapper的实现原理。
诚然，通过这样的方式设定Java Bean属性实在繁琐，但它却提供了一个通用的属性设定机制，而这样的机制，也正是Spring依赖注入机制所依赖的基础。

BeanFactory，顾名思义，负责创建并维护Bean实例。
BeanFactory负责根据配置文件创建Bean实例，可以配置的项目有：
1． Bean属性值及依赖关系（对其他Bean的引用）
2． Bean创建模式（是否Singleton模式，即是否只针对指定类维持全局唯一的实例）
3． Bean初始化和销毁方法
4． Bean的依赖关系
下面的代码演示了如何通过BeanFactory获取Bean实例：
InputStream is = new FileInputStream("bean.xml");
XmlBeanFactory factory = new XmlBeanFactory(is);
Action action = (Action) factory.getBean("TheAction");

十度（新环境，新同事…旧机器） 说：
哦。我们现在可能要用ejb来做，已经好久没用了。
raimundo-中午吃的方便面，就当是小温的寿面了 说：
好
raimundo-中午吃的方便面，就当是小温的寿面了 说：
到时候交流ejb实施经验
raimundo-中午吃的方便面，就当是小温的寿面了 说：
注意一点，千万不要拿entity bean做domain model....
十度（新环境，新同事…旧机器） 说：
嗯，国庆左右启动
raimundo-中午吃的方便面，就当是小温的寿面了 说：
不然你会死得很难看...
十度（新环境，新同事…旧机器） 说：
知道了
十度（新环境，新同事…旧机器） 说：
帖子不是白看的
raimundo-中午吃的方便面，就当是小温的寿面了 说：
这周你来吗？我们讨论一下ejb的组织
十度（新环境，新同事…旧机器） 说：
事务脚本是吧，哈哈
十度（新环境，新同事…旧机器） 说：
这周不是据说黄东来吗？crane联系的
十度（新环境，新同事…旧机器） 说：
过一阵再和你讨论ejb吧，都快忘光了，2年没用了
raimundo-中午吃的方便面，就当是小温的寿面了 说：
不光是，ejb组织里，最好按sub-system组织，不要分层
raimundo-中午吃的方便面，就当是小温的寿面了 说：
然后每个sub-system间用session facade交互...
十度（新环境，新同事…旧机器） 说：
看来你很有心得
raimundo-中午吃的方便面，就当是小温的寿面了 说：
每个facade的方法就是一个transaction-script
十度（新环境，新同事…旧机器） 说：
不分层吗？
raimundo-中午吃的方便面，就当是小温的寿面了 说：
对呀...以前用了好多ejb...好多次欲哭无泪...
raimundo-中午吃的方便面，就当是小温的寿面了 说：
ejb是组件架构，因此组件成为子系统，比较自然
raimundo-中午吃的方便面，就当是小温的寿面了 说：
分层是sub-system内的事情
十度（新环境，新同事…旧机器） 说：
子系统内也不分层？
raimundo-中午吃的方便面，就当是小温的寿面了 说：
不是架构的主题
raimundo-中午吃的方便面，就当是小温的寿面了 说：
内部要分
raimundo-中午吃的方便面，就当是小温的寿面了 说：
最好有一个dto/business/dao的framework
十度（新环境，新同事…旧机器） 说：
你的意思是整个系统不要分，sub里再分
raimundo-中午吃的方便面，就当是小温的寿面了 说：
对
raimundo-中午吃的方便面，就当是小温的寿面了 说：
把ui想成web ui sub-system
十度（新环境，新同事…旧机器） 说：
每个sub的分层也不一样吧
raimundo-中午吃的方便面，就当是小温的寿面了 说：
而不要想成presenation layer
raimundo-中午吃的方便面，就当是小温的寿面了 说：
这样你会舒服很多
raimundo-中午吃的方便面，就当是小温的寿面了 说：
sub根据需要来分
十度（新环境，新同事…旧机器） 说：
哦
raimundo-中午吃的方便面，就当是小温的寿面了 说：
比如用resouce接入的一个分法，用jms的，一个分法
raimundo-中午吃的方便面，就当是小温的寿面了 说：
分而治之
十度（新环境，新同事…旧机器） 说：
说实在的，你说的有些还不是十分清楚
raimundo-中午吃的方便面，就当是小温的寿面了 说：
画个图最好了
十度（新环境，新同事…旧机器） 说：
看来周六等让你当面“喷，喷”我了，呵呵
十度（新环境，新同事…旧机器） 说：
都是很好的经验
raimundo-中午吃的方便面，就当是小温的寿面了 说：
赫赫，==，我给你画个图
十度（新环境，新同事…旧机器） 说：
好
raimundo-中午吃的方便面，就当是小温的寿面了 说：
收
raimundo-中午吃的方便面，就当是小温的寿面了 说：
很粗糙...painter画的...
十度（新环境，新同事…旧机器） 说：
多谢 
十度（新环境，新同事…旧机器） 说：
sub系统是根据功能来划分的
十度（新环境，新同事…旧机器） 说：
？
raimundo-中午吃的方便面，就当是小温的寿面了 说：
？
十度（新环境，新同事…旧机器） 说：
你的子系统是根据功能来划分的？
raimundo-中午吃的方便面，就当是小温的寿面了 说：
可以，或者别的也行
raimundo-中午吃的方便面，就当是小温的寿面了 说：
这样比较好的原因是sub-system是比ejb更大粒度的组件
raimundo-中午吃的方便面，就当是小温的寿面了 说：
而ejb本身就要求很粗的重用
十度（新环境，新同事…旧机器） 说：
明白了，子系统划分的依据可以很灵活
raimundo-中午吃的方便面，就当是小温的寿面了 说：
一个facade之后大系统
raimundo-中午吃的方便面，就当是小温的寿面了 说：
正好使这个facade的session bean粒度非常大
raimundo-中午吃的方便面，就当是小温的寿面了 说：
作为重用单位很理想
raimundo-中午吃的方便面，就当是小温的寿面了 说：
而且把facade当作api的集合
十度（新环境，新同事…旧机器） 说：
只和facade打交道
raimundo-中午吃的方便面，就当是小温的寿面了 说：
对
raimundo-中午吃的方便面，就当是小温的寿面了 说：
这个是一个模式，叫business facade...
十度（新环境，新同事…旧机器） 说：
最好有一个dto/business/dao的framework

这句活什么意思？
raimundo-中午吃的方便面，就当是小温的寿面了 说：
非常好用
十度（新环境，新同事…旧机器） 说：
facade是包装了dao的？
raimundo-中午吃的方便面，就当是小温的寿面了 说：
其实就是out io/process/存储
raimundo-中午吃的方便面，就当是小温的寿面了 说：
就是一个处理过程的描述
十度（新环境，新同事…旧机器） 说：
哦
十度（新环境，新同事…旧机器） 说：
dto/business/dao/facade这样吧？
raimundo-中午吃的方便面，就当是小温的寿面了 说：
也还不太一样，最好还是画图
raimundo-中午吃的方便面，就当是小温的寿面了 说：
不过这就难画了...
十度（新环境，新同事…旧机器） 说：
哈哈
raimundo-中午吃的方便面，就当是小温的寿面了 说：
painter高不定....
十度（新环境，新同事…旧机器） 说：
dao之上应该有一个service的东西吧，service可以是简单的dao调用，也可以是关于事务的dao组合，再往上才应该是facade。不知道这样理解对不对？
raimundo-中午吃的方便面，就当是小温的寿面了 说：
这个facade是系统之外的东西
raimundo-中午吃的方便面，就当是小温的寿面了 说：
主要是交互的门面
raimundo-中午吃的方便面，就当是小温的寿面了 说：
也就是你系统内满足一定的逻辑自足
raimundo-中午吃的方便面，就当是小温的寿面了 说：
然后facade来调用
raimundo-中午吃的方便面，就当是小温的寿面了 说：
这样的好处，当有新的交互，增加一个facade
raimundo-中午吃的方便面，就当是小温的寿面了 说：
所以，facade，就该是delegate，而不该有额外的逻辑
raimundo-中午吃的方便面，就当是小温的寿面了 说：
除非是跟交互有关的
十度（新环境，新同事…旧机器） 说：
似乎理解了
十度（新环境，新同事…旧机器） 说：
还是face-to-face交流的好
raimundo-中午吃的方便面，就当是小温的寿面了 说：
这样才能体现灵活，而且，你发现没，如果facade了
raimundo-中午吃的方便面，就当是小温的寿面了 说：
后面用啥都行了
十度（新环境，新同事…旧机器） 说：
是呀
raimundo-中午吃的方便面，就当是小温的寿面了 说：
这就是soa的原型...
十度（新环境，新同事…旧机器） 说：
facade只是充当了门面的功能，
raimundo-中午吃的方便面，就当是小温的寿面了 说：
至今，主要的计算型soa还是这样实现的，把一个session facade声明成webService
十度（新环境，新同事…旧机器） 说：
其他的实现他不关心
raimundo-中午吃的方便面，就当是小温的寿面了 说：
好处是，这样的实现，解决了ws的短处，transaction！
raimundo-中午吃的方便面，就当是小温的寿面了 说：
ejb系统的强项就是transaction
raimundo-中午吃的方便面，就当是小温的寿面了 说：
而ws的弱项就是transaction
raimundo-中午吃的方便面，就当是小温的寿面了 说：
互补，很多大型soa架构都推荐这样的实现
十度（新环境，新同事…旧机器） 说：
经典
raimundo-中午吃的方便面，就当是小温的寿面了 说：
就算不用internet分布，内部使用，soa的灵活和延展也能得到体现
十度（新环境，新同事…旧机器） 说：
经你这么一说，明白了很多东西，要少走很多弯路
raimundo-中午吃的方便面，就当是小温的寿面了 说：
同时加强事务，是一种非常适合大型项目处理的architecture
raimundo-中午吃的方便面，就当是小温的寿面了 说：
哎~~~这就使那个电力市场项目给我的架构经验
raimundo-中午吃的方便面，就当是小温的寿面了 说：
同时利用j2ee每个container都可集群，都可pool的特点
十度（新环境，新同事…旧机器） 说：
值
raimundo-中午吃的方便面，就当是小温的寿面了 说：
failover非常好，也是高稳定架构的典范
十度（新环境，新同事…旧机器） 说：
failover是什么？
raimundo-中午吃的方便面，就当是小温的寿面了 说：
现在我在金山，是为了找到一种高并发架构的典范
raimundo-中午吃的方便面，就当是小温的寿面了 说：
容灾
raimundo-中午吃的方便面，就当是小温的寿面了 说：
防止单点失败
raimundo-中午吃的方便面，就当是小温的寿面了 说：
也就是以前说的什么多机容错之类的东东
十度（新环境，新同事…旧机器） 说：
我们这里好像别的部门也在弄，具体还不清楚
raimundo-中午吃的方便面，就当是小温的寿面了 说：
如果高稳定，这个结构就够了，高并发我并不看好，ejb的序列化太多了，性能很难讲
raimundo-中午吃的方便面，就当是小温的寿面了 说：
如果你做企业，这么做肯定不会错的
十度（新环境，新同事…旧机器） 说：
 
raimundo-中午吃的方便面，就当是小温的寿面了 说：
嘿，你看我要做咨询也不错吧
十度（新环境，新同事…旧机器） 说：
更适合干传销
十度（新环境，新同事…旧机器） 说：
绝对有蛊惑力
十度（新环境，新同事…旧机器） 说：
有的时候，理论知道了，但是写代码的时候还是会不由自主的犯错误
十度（新环境，新同事…旧机器） 说：
有能借鉴的吗？
raimundo-中午吃的方便面，就当是小温的寿面了 说：
这个东西我摸索了一阵，才想出来，当时做的很郁闷，有一次推倒重写....
raimundo-中午吃的方便面，就当是小温的寿面了 说：
core j2ee patterns 2ed
raimundo-中午吃的方便面，就当是小温的寿面了 说：
business facade
十度（新环境，新同事…旧机器） 说：
 推倒重写，有勇气，还是被逼得？
十度（新环境，新同事…旧机器） 说：
好，我去找些资料看看
raimundo-中午吃的方便面，就当是小温的寿面了 说：
实在写不下去了...
raimundo-中午吃的方便面，就当是小温的寿面了 说：
我自己推的...
十度（新环境，新同事…旧机器） 说：
那你重写，就不怕还不成功
raimundo-中午吃的方便面，就当是小温的寿面了 说：
好在ui层用lightweight container装配
raimundo-中午吃的方便面，就当是小温的寿面了 说：
有mock实现，可以骗一下领导...
十度（新环境，新同事…旧机器） 说：
哈哈
raimundo-中午吃的方便面，就当是小温的寿面了 说：
争取了一些时间
十度（新环境，新同事…旧机器） 说：
我要把今天的谈话记录下来，慢慢在研究一下
raimundo-中午吃的方便面，就当是小温的寿面了 说：
嘿嘿
十度（新环境，新同事…旧机器） 说：
多谢了啊
raimundo-中午吃的方便面，就当是小温的寿面了 说：
赫赫，不客气
raimundo-中午吃的方便面，就当是小温的寿面了 说：
共同进步嘛...
十度（新环境，新同事…旧机器） 说：
呵呵

昨天是新单位上班的第一天，充满了好奇、期待……，简单地说就是复杂的心情啦。

早上8：20人力部的一位热心同事接待了我，叮嘱了一些事情，填了一些表格。8：45终于来到自己的办公桌旁边，不过桌子上什么也没有，坐在桌子旁边无所事事，看着其他同事很忙碌的样子，很想看看他们在干什么。后来在领导的带领下和一些主要的同事熟悉了一下。之后，电脑还没送来，还是没事儿干，突然看见旁边一个同事的桌子上放着《敏捷软件开发》，我也买了，就是还没看，于是借过来看。

12：00---13：00出去吃饭。回来继续看书，迷迷糊糊的看完两章之后，已经将近16：00，我的电脑终于ok了，经过漫长的等待之后，发现等来电脑的配置：p3 1G；512M cpu；20G 硬盘……让我仿佛回到了一年前，里边还有许多别人留下的东西，瀑布汗呀！后来想想无所谓了，武功高，不用好兵器也能对付敌人了。以后好像还能换。

16：00---18：00给我的机器装东西，还没干完，先回家。

心得：不要对事情期望的太高。

昨天去了一个还不错的公司去第二轮面试，这次面试我的是技术总监，难免紧张。和技术有关的问题也就谈了20分钟，就开始和我谈待遇了，当时就懵了（第一次面试的时候虽然自己感觉还可以，但是没想到这次这么快就开始谈待遇了，根本就没有准备呀）。然后就是按部就班的问我期望薪金…………最失败的是他说了他们可以提供的薪金之后，我居然想了想就答应了，因为后来我觉得如果我在坚持一下，还可以涨一些，损失了几百块，后悔！！！

工资还好说，进去之后好好干，才是最重要的，问题是下面还有更失败的：一直到最后我都没问公司开发有多少人，人员组成，使用什么技术…………稀里糊涂的就结束了这次面试。这次经历和前几天七彩狼的面试经历极为相似，他当时也是傻乎乎的，回来之后也是后悔不已。

后来想想，也知足了，部门里面想走的兄弟基本都找好了，我差不多是最后一个了，找到一个比较理想的工作之后也可以省心了。

由于某些原因，现在我们软件部的人们大部分准备要辞职了，今天一个关系挺好的同事已经离职了，到下个月估计就剩不了几个人了，唉……

大家来这里虽然不长时间，但是现在这个团队磨合的确实很棒，无论是技术水平，还是气氛环境都是很难得的。可是想不到还是要分开了，不是因为做得东西不好，不是因为任务完成不了，原因实在是很无奈。公司虽然也不错，但是也到不了舍不得走的程度，最舍不得的还是这些同事。当时我们也想争取跳到同一家公司，但是不太现实，希望以后能有机会再聚到一起吧。