spring对象缓存

         用过spring的人都知道 spring的注入方式很方便，它自己维护着一个容器来管理你需要的bean，但是背后真正的原因是什么呢。

         以前我们都是在用到的时候来直接new 或者工厂类间接create一个，有了spring 我们就有了一个统一的管理入口，对于管理层面来说他真的很明智。再看看spring的对象缓存，当然大家异口同声的说 我用的时候就不用来个新的了，直接使用了，出于性能和管理都是很方便而且重要的，而且数据得到了一致性保证。其实这个缓存的最大目的是对于性能考虑（当然都觉得是废话了），不要以为new一个对象的开销很小，的确你只new一个轻量级对象当然很小了，但是你多次使用重量级对象，而且这个对象的继承度很深，比如至少2个继承的层次，抑或聚合的对象很多，比如一个类里聚合了至少几个其他大类， 当系统真正运行起来，频繁的new这些重量级的对象时你的系统的性能一定要下降。我这里并不想讨论什么new对象的开销问题，我只想说spring的性能大部分得益于他的缓存设计，当你使用spring的时候有考虑过他的性能吗。所以我想说每每用他的时候在思考下他的设计我都能学到很多设计理念，当然我还是很菜很菜的菜鸟。

         写到这里我想起了公司里硕大的一个baseEntity，很多的属性在里面，然后这个baseEntity被继承了好几次都是为了满足某次小小的需求然后整合老系统。在通用性和小巧性之间我总是很矛盾，小巧性必然会打破所谓的重用，有的时候过度的重用真的很累赘，做个1+1的问题也要搬个银河上来。我并不反对重用，只是在小巧明晰上我喜欢简单，当然重用和简单并不直接冲突，只是在实现上会有所隔阂。这里把baseEntity拉进来的目的其实想说的是与之有关的性能问题，为了业务明确传递一个bean进去然后这个bean很繁重，但是我们只用他的一小部分，查询一个对象时我们总是返回一个硕大的bean回去，然后大部分字段都是null，哎，算了，看各人爱好吧。其实重用真的还很难把握。