java池化

❶ java问题：Cannot create PoolableConnectionFactory

不能建立池化连接工厂

你检查你的数据源配置，例如数据库地址、url、用户名、密码
如果这些都对，那么再检查网络连接，包括你这边和数据库服务器那边的。

这个错误总之就是不能连接数据库产生的

❷ 【Java基础】线程池的原理是什么

什么是线程池？

总归为：池化技术 ---》数据库连接池 缓存架构 缓存池 线程池 内存池，连接池，这种思想演变成缓存架构技术---> JDK设计思想有千丝万缕的联系

首先我们从最核心的ThreadPoolExecutor类中的方法讲起，然后再讲述它的实现原理，接着给出了它的使用示例，最后讨论了一下如何合理配置线程池的大小。

Java 中的 ThreadPoolExecutor 类

java.uitl.concurrent.ThreadPoolExecutor 类是线程池中最核心的一个类，因此如果要透彻地了解Java 中的线程池，必须先了解这个类。下面我们来看一下 ThreadPoolExecutor 类的具体实现源码。

在 ThreadPoolExecutor 类中提供了四个构造方法：

❸ java软件开发的架构设计

软件架构作为一个概念，体现在技术和业务两个方面。
从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。
先说一些基本原则：
分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。
模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。
接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。从这个原则出发，软件也从微观进行了细致的规范化。
还有两个比较小但很重要的原则：
细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade(外观)模式就很能体现这个原则的精神。
依赖倒置原则随着软件结构的进一步发展,层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。这个原则有点类似于知名的好莱坞法则：Don't call us, we'll call you。
以上这些原则奠定了我们的软件架构的价值指标。但软件架构毕竟是建立在当前技术之上的。而每一代技术都有架构模式。过去的不再说了，让我们就来看一下当前流行的技术，以及当前我们能采用的架构。
因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。我们从三层次架构谈起：
因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。推荐作为持久层的首选
在业务层，因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。
在用户结构层,虽然servlet/jsp/jstl/javaBean 能够实现MVC架构，但终究过于粗糙。struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。
因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致 性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务(tool:jaas)、流程控制服务workflow、动态实现服务IOC，串行化消息服务(tool:jms)、负载平衡服务blance等。如果我们不采用重量级应用服务器(如weblogic,websphere,jboss等)及重量级组件(EJB)，我们必须自己实现其中一些服务。虽然我们大 多情况下，不需要所有这些服务，但实现起来却非易事。幸运的是我们有大量的开源实现代码，但采用开源代码却常常是件不轻松的事。
随着xml作为结构化信息传输和存储地位日渐重要,一些xml文档操作工具(DOM,Digester,SAX等)的使用愈发重要，而随着 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，采用xml schema来设计xml文档格式，然后采用java binding来生成java bean 会成为主要编程模式,而这又进一步使数据中心向xml转移，使在中小数据量上,愈发倾向于以xquery为查询语言的xml数据库。现还有一个趋势， microsoft,ibm等纷纷大量开发中间软件如(microsoft office之infopath)，可以直接从xml schema 生成录入页面等非常实用的功能。还有web service 的广泛应用，都将对软件的架构有非常重大的影响。至于面向服务架构(SOA)前景如何，三层次架构什么时候走入历史，现还很难定论。
aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、 nanning都有其自身的严重问题：维护性很差，所以说它将很难走远。也许作为一个很好的思想，它将在web service里大展身手。
rdf,owl作为w3c语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。但如果真如它所声称那样，广泛地改变着信息的结构。那么对软件架构也会有深远影响。

❹ .net和java的区别及各自的优缺点

平台之争 Java与.NET谁更有前途
2009-2-18 网友评论 1 条 点击进入论坛
为什么会有Java，为什么会有.NET

有人说，Java是为了跨Windows和UNIX而产生的。是这样吗?Sun有自己的操作系统solaris，并且打的是高端市场，而Java发展早期阶段，Windows还主要定位在中小型企业，并没有打算与Sun一争高端客户。

而且Sun的用户大部分都是大型企业级，而Windows定位在家庭消费用户，由于Windows已经成为桌面OS的事实标准，Sun根本无意抢夺 Windows的地盘，而且Sun有自己的操作系统，扩大自己产品销售才是第一。

但是UNIX一直是个混乱的世界,各种UNIX版本在并存,你为这种 UNIX开发的应用,却很难在另一种UNIX上跑通.应用的阻塞影响了UNIX市场需求的扩大,就象没有SQL Server,没有OFFICE,没有Windows 游戏,和Windows上的开发工具,就算你的操作系统做的再漂亮再容易我们也会扔掉Windows.为什么?因为没用,我买回来一个大铁家伙,我什么也做不了.Sun就出于这种考虑,所以才有VM的想法,否则谁傻了,做个又慢又麻烦的VM.所以说Java的产生,只是为了跨UNIX平台.当然能跨 Windows,吃定Windows,那岂不是更好,呵呵呵,Sun为自己的妙招而没事偷着乐.

那为什么会有.NET呢?可是Windows就一个呀,它也要跨平台?而且微软已经把CLI提交给标准委员会,看来是真要跨了?真的吗?

从外表来看,Windows确实是一个.但是从技术角度来看,Windows3,Windows95,Windows2000是截然不同的三种架构.在中国,大家对新技术的追求比较热衷,所以说一个企业中这三种操作系统并存互连的可能性不怎么大.但是老外是精打细算,不见兔子不撒鹰,所以你在国外企业运行很老的系统也不要见怪.微软为了同时维护这几种操作系统也是煞费苦心,而且由于技术是各个时期形成的,有的技术由于历史发展原因有明显的缺陷,也无能为力修改了,而且为了功能更强大,API海洋,DLL黑洞,ACTIVEX,OLE,COM,DCOM,COM+,各种技术交叉,唉,其中苦谁了解?所以跨WINDWOS平台是微软制造.NET的一个原因,这样给你一个抽象的统一的平台后把你摆平后,他再着手修改他的底层,省得一天人们叫着 Windows不安全,Windows不稳定.当然从J2EE的火热场面来看,拉去了很大一批Windows平台上的C++程序员.失去了应用开发的源头,那还有什么发展?如何拉回这批程序员让他们继续为Windows开发当然也是.NET的原因之一,这就是为什么.NET从架构到开发语言都与 Java极其相似的原因,就是吸引你平滑的再回到微软的世界中,如果跨度大了,程序员就有了迟疑.唉,如果没有Java,如今的C#也不会是如今这样,原本它会更好,我想ANDERS一定心中很郁闷,但是商业是不以个人意志为转移的.而且现在已经不是桌面为王的时代了,现在是互连网的时代,Java是第一个有强大开发WEB应用的完整体系,而当时微软的技术还是七拼八凑,只是互连网一下到来微软刚醒过神来仓促应战的结果,当然无法与J2EE媲美.想在互连网时代也分一杯羹,必须也有一个完整的体系,于是.NET就产生了.

我们已经有了Web Service,我们还需要.NET吗?

其实技术发展到如今的应用集成时代,用户的需求就是把现在各种平台上的应用集成起来.集成的方法有很多种,当然跨平台也是一种.不过最省力的还算是WEB SERVICE.因为现在已经是组件应用的天下.各种COM,EJB,CORBA成为快速组装企业应用的主流技术.组件是位于操作系统,数据库,网络之上的技术,站在组件的层面上,下面用什么技术已经无所谓了,因为已经被组件屏蔽了.如果我们能把我们的组件互连起来,不也可以集成吗?应该怎么做?这几项技术都分属于不同公司,想联合真不大容易.这时就要找到每个体系公共的东西,用公共的东西把他们连在一起不就行了.找呀找,终于发现,是TCP/IP.随即几大公司都发现了突破口,需要快速占领先机.由于Sun一直在Java发展的问题上给了IBM很大的阻塞,所以IBM宁愿先和微软联合做,如果微软有什么不轨之心,就放出Sun,让他们互相咬,然后在适当的时机出来装出老大的样子摆平他们,给他们俩制定一个适合自己发展的竞争协议.

我们已经可以互连了,我们干吗要.NET.我们的问题已经解决了,我干吗花钱再投资呢?经济本来已经很不景气了.

但是,微软看来已经决定不在现有基础上增强ASP和COM+了,现在是互连时代,也是组件时代,两大要命的地方我都不升级了,你自己看着办,我可没逼着你买.

.NET和Java在中国哪个更有前途?

这个问题好象已经不用再争了.中国90%的用户是Windows用户,保护现有投资,使用很习惯很易用不用重新学习,我又不用跨平台,我干吗要换Java 呢.过去是微软没有提供很强大的WEB开发解决方案,现在提供了,我干吗要用Java.而且. Net比Java出的迟,肯定会吸收Java的优点,弥补Java的缺点.而且微软的VM肯定和Windows结合的很好,性能不用担心.我干吗用 Java?而且微软显然把宝已经压到了.NET上,你难道还要在.NET的VM上再加一层Java的VM?

.NET有什么新的亮点?

当然是ASP,ADO和COM+,还有清晰的架构,并且由于统一的类库,我们为WEB,GUI,MOBILE而开发的应用会很容易的转来转去,不象过去开发,各需要学习不同的知识.ASP终于结束了网页意大利面条式的程序,面向对象和支持多种语言,使构筑强大复杂的WEB应用提供了比JSP更凶猛的功能,让人不得不爱.ADO.NET也抛弃了过去的数据集一Scroll就连数据库进行提交的糟糕速度,代而取之的是多条修改可以一次性提交上去.这样性能会提高很多.COM+呢?COM+1.5的特性大家在WINXP上也看见了,比1.0强了很多,未来还不用注册, COPY完就能用,多舒服.至于安全嘛,稳定嘛,这话不敢讲.因为盗亦有道,Java也同样如此,无法说谁比谁好.

.NET真的会跨平台吗?

微软的命根子是操作系统,微软此次出.NET也是为了打入高端市场.怎么打入?微软第一已经在用C#收买 Java程序员了,并且做Java和C#的映射工具,先断了Java应用的前途,后面用CLI提交给标准委员会,让别人开发UNIX上的平台,微软不在正面和UNIX阵营冲突,以免犯众怒.当UNIX和Windows的CLI都有了时候,基于CLI的应用可就两个系统都能用了,这会帮助微软销售多少其他产品呀.这不,微软在支持着好几个Open Source社团在开发UNIX的CLI.跨平台的事微软不会轻易干的,否则微软的命根子怎么办?

.NET真的支持多种语言吗?

开发更多的基于.NET的应用,让.NET快速成长起来.第二.NET是一次比较大的革新,广大的各类程序员能否跟的上也是个问题.多语言的支持当然会,但是不会支持的很好,否则微软大力做C#干吗呀,如果别的语言和C#一样好,那微软还混什么混呀.最糟糕了,也要其他语言的技术比C#慢半拍.不过先走也未必领先,就象DELPHI就后来居上,这么大的市场,微软是不可能通吃的.

我们需要转到.NET上吗?

你可以不转.就看你需要不需要INTERNET了.我想在未来,没有企业会说INTERNET对我没有一点作用.

现有应用能否平滑过渡呢?

在这个问题上可以看一下微软的历史.微软在做完WINNT4的时候其实已经在策划现在的WIN2000,但是为什么在WIN95后有WIN98, WINME,WINXP,不是他当时做不了那样的技术,而是必须引导着客户一步步走,要追随客户,走的太快,就会丢失客户.在这个重大的转折点,微软也会如此.而且在现在的Windows.NET上,你运行现在的程序一样没问题,速度依旧,操作方式也依旧,因为他使用了两种手段来区别对待这两种应用程序.

什么时候转?

如果你需要抢占市场先机,现在转正好,因为能支持ASP.NET,ADO.NET开发的VSS.NET已经推出快一年了,就是有能力欠缺的问题,第二版的出来也不会太晚了.不过话在前头,确实在实际的开发中,Vss.NET确实有些做不了的事情,不要看他好象什么都有,这就跟微软当年宣布COM有池化的功能一样,仅有一个外壳.这是微软的策略,跟不跟着走,你自己看.稳健型的公司建议在第二版出来后应用,因为微软的产品一向在第三版才会好用.

作为开发商,跟随.NET的难点是什么?

难点难就在,过去我们的开发方式,拖一些控件,连个数据库,更新或SELECT一些数据.再深一些就是消息,或者是一些不常用的API.记住:.NET是微软进攻高端市场的第一步,现在的微软不是我们过去熟悉的微软,Vss.NET的一推出,就是强烈给人一种这样的感受:从建模到开发到测试到发布,全套企业级的工具都无缝相接,而且处处体现着OO和设计模式,在宣传中也频繁提到,昭示着这个工具是为大型应用开发而定制的.所以宝刀也需有能力的人才能拿的动,否则只能砸了自己的脚.对于现在的Java开发工具也是如此,好象全世界一下都没有了小型企业一样.我们是否具备了优秀的设计师,建模师,OOP的程序员,我们是否有一整套流畅的开发流程来支持全程建模,我们都需要深思.在微软的.NET的各种培训上,培训师也是反复强调分析设计,大型项目管理,自动化工具的支持,你做好准备了吗?

Sun在微软拆分问题上输了吗?

微软的案子打了这么多年,居然庭外和解.Sun确实挺郁闷.不过Sun并没有输.为什么这么说呢?依毛主席的话说就是:敌进我退,敌疲我扰.确实微软在. NET的发展上受了很多牵绊,否则也不会到如今才推出来个框架.在硅谷,时间就是机会,时间就是金钱,谁前进的快谁就能占先机,显然Sun并不是最痛苦的一个.

Java的未来

依Windows的用户量和微软进攻高端企业应用的决只是呆板的图形,不能全方位的表现网络的传输技术,使应用进步更加依赖硬件而不是软件,微软亚洲研究院为什么在做哪些研究,就是因为他们不断在思考未来是什么,所以每一次技术的浪潮他们总在浪头.当然未来还会有所改变,但是他们会及时调整他们的战略,但大方向不会错到哪去!

当技术不再是阻碍应用发展的主要因素,比如宽带的来临,这时候你想过没有,在它上面,该做些什么呢?世界有多大,你能看多远?为什么在每次浪潮到来时你都无法预想到,而感叹这世界变化如此之快?

我对微软的发展的一些看法:

微软把.NET扩展到高端市场和移动设备市场,为.NET开发的程序可以在基于.NET的任何设备上都可以运行,大家不需要为不同的设备用不同的工具开发应用,应用极大的推动了基础软件的扩大,就象OFFICE,SQL Server辅助扩大了Windows的销售一样.

未来的XBOX也会变成.NET平台,成为家庭连网的安全网关和交易网关和信息网关,如果你觉得微软进入游戏业就是为了眼馋游戏这块利润,那你就大错特错了,这个皮毛根本不值得微软大动这么财力.

PDA和手机也和机顶盒一样嵌入.NET,你打开电视,你打电话,你玩游戏,你工作,你上网,你甚至打开冰箱,你都不会知道在背后支撑的是.NET,从高端服务器到你的手机,全部是微软的软件这是一个伟大的设想,如果微软能够兢兢业业的走,凭这样的财力人力和管理和经营战略,走10年,实现的可能性非常大,这不是以个人意志为转移的,你说他倒他就会倒吗?

如果会成功,当然微软会成为人类历史上最伟大的公司,赚取的财富已经不能再提,最关键的问题是:我们全人类的生活和工作被一个私人的商业公司所控制着.

只是到那个恐怖的地步,你是否有勇气和能力把他拆分.因为他足以触及到你的生活和工作,社会的经济,政治活动,甚至军事,任何的动作都足以引起社会的大地震.你认为他有什么理由完不成这些梦想吗?

❺ java 代码用dbcp 怎么替换

1，连接池创建
BasicDataSource -> DataSource
@Override
public Connection getConnection()
【a】createDataSource()
如果dataSource不为空，则返回数据源对象，否则创建之，如下：
【1】createConnectionFactory()
(a)通过配置参数<property name="driverClassName" value="${jdbc.driver}" />，加载驱动类Class.forName(driverClassName);
(b)通过配置参数<property name="url" value="${jdbc.url}" />，获取驱动DriverManager.getDriver(url)；
(c)通过配置参数<property name="username" value="${jdbc.username}" />，<property name="password" value="${jdbc.password}" />，
以及driver，url，创建数据库连接工厂new DriverConnectionFactory(driver, url, connectionProperties);
【2】createConnectionPool()
(a)通过配置参数：<property name="maxActive" value="${dbcp.maxActive}" />
<property name="maxIdle" value="${dbcp.maxIdle}" />
<property name="minIdle" value="${dbcp.minIdle}" />
等配置项，创建连接池org.apach.commons.pool.impl.GenericObjectPool connectionPool
commons-dbcp本身不创建连接池，通过commons-pool来管理连接池
(b)GenericObjectPool.addObject()中调用下步创建的连接池工厂类，创建连接，并通过addObjectToPool(obj, false);将连接保存在连接池
【4】(driverConnectionFactory, statementPoolFactory, abandonedConfig)
(a)创建连接池工厂类PoolableConnectionFactory，工厂类内部将该工厂设置到上步创建的connectionPool中，这样就可以通过connectionPool中的addObject()调用连接池工厂创建连接
【5】createDataSourceInstance()
(a)根据连接池connectionPool创建池化数据源对象 PoolingDataSource pds = new PoolingDataSource(connectionPool)
【6】初始化连接
for (int i = 0 ; i < initialSize ; i++) {
connectionPool.addObject();
}
【7】返回池化数据库连接对象dataSource
【b】getConnection()
【1】_pool.borrowObject()；调用【a】-【2】创建的连接池创建连接
(a)_factory.makeObject()；调用【a】-【4】创建的连接池工厂类对象，返回new PoolableConnection(conn,_pool,_config);对象
其中PoolableConnection持有【a】-【2】创建的连接池_pool，当PoolableConnection.close()时，该连接会被_pool回收，_pool.returnObject(this);

❻ Java的有几种技术架构

Java架构：

软件架构作为一个概念，体现在技术和业务两个方面。
从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。
先说一些基本原则：
分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。
模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。
接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。从这个原则出发，软件也从微观进行了细致的规范化。
还有两个比较小但很重要的原则：
细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade（外观）模式就很能体现这个原则的精神。
依赖倒置原则随着软件结构的进一步发展,层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。这个原则有点类似于知名的好莱坞法则：Don't call us, we'll call you。

以上这些原则奠定了我们的软件架构的价值指标。但软件架构毕竟是建立在当前技术之上的。而每一代技术都有架构模式。过去的不再说了，让我们现在就来看一下当前流行的技术，以及当前我们能采用的架构。

因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。我们从三层次架构谈起：
因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。推荐作为持久层的首选
在业务层,因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。
在用户结构层,虽然servlet/jsp/jstl/javaBean 能够实现MVC架构,但终究过于粗糙。struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。
因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务(tool:jaas)、流程控制服务workflow、动态实现服务IOC，串行化消息服务(tool:jms)、负载平衡服务blance等。如果我们不采用重量级应用服务器(如weblogic,websphere,jboss等)及重量级组件(EJB)，我们必须自己实现其中一些服务。虽然我们大多情况下，不需要所有这些服务，但实现起来却非易事。幸运的是我们有大量的开源实现代码,但采用开源代码却常常是件不轻松的事。

随着xml作为结构化信息传输和存储地位日渐重要,一些xml文档操作工具(DOM,Digester,SAX等)的使用愈发重要,而随着xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，采用xml schema来设计xml文档格式,然后采用java binding来生成java bean 会成为主要编程模式,而这又进一步使数据中心向xml转移,使在中小数据量上,愈发倾向于以xquery为查询语言的xml数据库。最近还有一个趋势,microsoft,ibm等纷纷大量开发中间软件如(microsoft office之infopath)，可以直接从xml schema 生成 录入页面等非常实用的功能。还有web service 的广泛应用，都将对软件的架构有非常重大的影响。至于面向服务架构(SOA)前景如何，三层次架构什么时候走入历史，现在还很难定论。

aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、nanning都有其自身的严重问题:维护性很差,所以说它将很难走远。也许作为一个很好的思想，它将在web service里大展身手。

rdf,owl作为w3c语义模型的标志性的语言,也很难想象能在当前业务架构发挥太大影响。但如果真如它所声称那样，广泛地改变着信息的结构。那么对软件架构也会有深远影响。

有关架构设计的一些忠告：
尽量建立完整的持久对象层.可获得高回报
尽量将各功能分层,分块,每一模块均依赖假定的其它模块的外观
不能依赖静态数据来实现IOC模式，应该依赖数据特征接口，静态数据仅是数据特征接口实现方式之一
架构设计时xml是支持而不是依赖.但可以提供单一的xml版本的实现

从业务角度说：软件架构应是深刻体现业务内部规则的业务架构，但因为业务变化频纴，所以软件架构很难保持恒定不变，但业务的频繁变化不应是软件架构大规模频繁变化的原因，软件架构应是基于变化的架构。
一种业务有其在一段时间内稳定存在的理由(暂且不谈)，业务内部有许多用例，每一种用例都有固定的规则，每一规则都有一些可供判定的项，每一项从某一维度来观察都是可测量的，我们的架构首先必须保证完美适应每一项每一种测量方式，很多失败的架构都是因为很多项的测量方式都发生变更这种微观变化中。

每个用例都有规则，我们在作业务用例分析，常常假定一些规则是先验的，持久稳定的，然而后来的业务改变常常又证明这种看法是错误的，然而常常我们的架构已经为之付出了不可挽回的代价。大量事实证明：规则的变化常常用例变化的根本原因。所以我们的架构要尽可能适应规则的变化，尽可能建立规则模版。

每个用例都关系着不同的角色。每一个用例的产生都必然是因为角色的变更（注意：不是替换，而是增强或减弱），所以注意角色的各种可能情况，对架构的设计有举足轻重的意义。在我们当前的三层架构里，角色完美地对应接口概念。

在一个系统里很多用例都相互关联,考虑到每个用例均有可能有不同的特例，所以在架构设计中，尽量采用依赖倒置原则。如架构许可可采用消息通信模式(JMS)。这样可降低耦合度。

现在我们谈一下业务稳定存在理由对业务的影响。存在即是合理，在这里当然是正确的。业务因人而存在，所以问业务存在的理由即是问不同角色的需要这项业务的理由以及喜欢不喜欢当前业务用例的理由，所有这样的角色都应该在系统里预留。《待续》
在架构设计中有几个原则可以考虑：
用例尽量细分
用例尽量抽象
角色尽量独立
项测量独立原则
追求简单性
这里未提供相关的例子，例子会在以后的更新时提供。

业务和模式之间的关系
业务中的一些用例之间的关系常常和一些常规的模式很相似。但随着时间的演化，慢慢地和先前的模式有了分歧。这是个正常的现象。但这对系统架构却要求非常高，要求系统架构能适应一些模式的更替。在这里我们尽可能早地注意到用例之间的相互角色变化，为架构更新做好准备.

❼ Java线程池中的核心线程是如何被重复利用的

Java线程池中的核心线程是如何被重复利用的？

引言

在Java开发中，经常需要创建线程去执行一些任务，实现起来也非常方便，但如果并发的线程数量很多，并且每个线程都是执行一个时间很短的任务就结束了，这样频繁创建线程就会大大降低系统的效率，因为频繁创建线程和销毁线程需要时间。此时，我们很自然会想到使用线程池来解决这个问题。

使用线程池的好处：

• 降低资源消耗。java中所有的池化技术都有一个好处，就是通过复用池中的对象，降低系统资源消耗。设想一下如果我们有n多个子任务需要执行，如果我们为每个子任务都创建一个执行线程，而创建线程的过程是需要一定的系统消耗的，最后肯定会拖慢整个系统的处理速度。而通过线程池我们可以做到复用线程，任务有多个，但执行任务的线程可以通过线程池来复用，这样减少了创建线程的开销，系统资源利用率得到了提升。

• 降低管理线程的难度。多线程环境下对线程的管理是最容易出现问题的，而线程池通过框架为我们降低了管理线程的难度。我们不用再去担心何时该销毁线程，如何最大限度的避免多线程的资源竞争。这些事情线程池都帮我们代劳了。

• 提升任务处理速度。线程池中长期驻留了一定数量的活线程，当任务需要执行时，我们不必先去创建线程，线程池会自己选择利用现有的活线程来处理任务。

很显然，线程池一个很显着的特征就是“长期驻留了一定数量的活线程”，避免了频繁创建线程和销毁线程的开销，那么它是如何做到的呢？我们知道一个线程只要执行完了run()方法内的代码，这个线程的使命就完成了，等待它的就是销毁。既然这是个“活线程”，自然是不能很快就销毁的。为了搞清楚这个“活线程”是如何工作的，下面通过追踪源码来看看能不能解开这个疑问。

分析方法

在分析源码之前先来思考一下要怎么去分析，源码往往是比较复杂的，如果知识储备不够丰厚，很有可能会读不下去，或者读岔了。一般来讲要时刻紧跟着自己的目标来看代码，跟目标关系不大的代码可以不理会它，一些异常的处理也可以暂不理会，先看正常的流程。就我们现在要分析的源码而言，目标就是看看线程是如何被复用的。那么对于线程池的状态的管理以及非正常状态下的处理代码就可以不理会，具体来讲，在ThreadPollExcutor类中，有一个字段private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));是对线程池的运行状态和线程池中有效线程的数量进行控制的， 它包含两部分信息: 线程池的运行状态 (runState) 和线程池内有效线程的数量 (workerCount)，还有几个对ctl进行计算的方法:

• // 获取运行状态


• private static int runStateOf(int c) { return c & ~CAPACITY; }



• // 获取活动线程数


• private static int workerCountOf(int c) { return c & CAPACITY; }123456



以上两个方法在源码中经常用到，结合我们的目标，对运行状态的一些判断及处理可以不用去管，而对当前活动线程数要加以关注等等。

下面将遵循这些原则来分析源码。

解惑

当我们要向线程池添加一个任务时是调用ThreadPollExcutor对象的execute(Runnable command)方法来完成的，所以先来看看ThreadPollExcutor类中的execute(Runnable command)方法的源码：

• public void execute(Runnable command) {


• if (command == null)


• throw new NullPointerException();



• int c = ctl.get();


• if (workerCountOf(c) < corePoolSize) {


• if (addWorker(command, true))


• return;


• c = ctl.get();


• }


• if (isRunning(c) && workQueue.offer(command)) {


• int recheck = ctl.get();


• if (! isRunning(recheck) && remove(command))


• reject(command);


• else if (workerCountOf(recheck) == 0)


• addWorker(null, false);


• }


• else if (!addWorker(command, false))


• reject(command);


• }



按照我们在分析方法中提到的一些原则，去掉一些相关性不强的代码，看看核心代码是怎样的。

• // 为分析而简化后的代码


• public void execute(Runnable command) {



• int c = ctl.get();


• if (workerCountOf(c) < corePoolSize) {


• // 如果当前活动线程数小于corePoolSize，则新建一个线程放入线程池中，并把任务添加到该线程中


• if (addWorker(command, true))


• return;


• c = ctl.get();


• }



• // 如果当前活动线程数大于等于corePoolSize，则尝试将任务放入缓存队列


• if (workQueue.offer(command)) {


• int recheck = ctl.get();


• if (workerCountOf(recheck) == 0)


• addWorker(null, false);


• }else {


• // 缓存已满，新建一个线程放入线程池，并把任务添加到该线程中（此时新建的线程相当于非核心线程）


• addWorker(command, false)


• }


• }22



这样一看，逻辑应该清晰很多了。

• 如果 当前活动线程数 < 指定的核心线程数，则创建并启动一个线程来执行新提交的任务（此时新建的线程相当于核心线程）；

• 如果 当前活动线程数 >= 指定的核心线程数，且缓存队列未满，则将任务添加到缓存队列中；

• 如果 当前活动线程数 >= 指定的核心线程数，且缓存队列已满，则创建并启动一个线程来执行新提交的任务（此时新建的线程相当于非核心线程）；

接下来看addWorker(Runnable firstTask, boolean core)方法

• private boolean addWorker(Runnable firstTask, boolean core) {


• retry:


• for (;;) {


• int c = ctl.get();


• int rs = runStateOf(c);



• // Check if queue empty only if necessary.


• if (rs >= SHUTDOWN &&


• ! (rs == SHUTDOWN &&


• firstTask == null &&


• ! workQueue.isEmpty()))


• return false;



• for (;;) {


• int wc = workerCountOf(c);


• if (wc >= CAPACITY ||


• wc >= (core ? corePoolSize : maximumPoolSize))


• return false;


• if ((c))


• break retry;


• c = ctl.get(); // Re-read ctl


• if (runStateOf(c) != rs)


• continue retry;


• // else CAS failed e to workerCount change; retry inner loop


• }


• }



• boolean workerStarted = false;


• boolean workerAdded = false;


• Worker w = null;


• try {


• w = new Worker(firstTask);


• final Thread t = w.thread;


• if (t != null) {


• final ReentrantLock mainLock = this.mainLock;


• mainLock.lock();


• try {


• // Recheck while holding lock.


• // Back out on ThreadFactory failure or if


• // shut down before lock acquired.


• int rs = runStateOf(ctl.get());



• if (rs < SHUTDOWN ||


• (rs == SHUTDOWN && firstTask == null)) {


• if (t.isAlive()) // precheck that t is startable


• throw new IllegalThreadStateException();


• workers.add(w);


• int s = workers.size();


• if (s > largestPoolSize)


• largestPoolSize = s;


• workerAdded = true;


• }


• } finally {


• mainLock.unlock();


• }


• if (workerAdded) {


• t.start();


• workerStarted = true;


• }


• }


• } finally {


• if (! workerStarted)


• addWorkerFailed(w);


• }


• return workerStarted;


• }



同样，我们也来简化一下：

• // 为分析而简化后的代码


• private boolean addWorker(Runnable firstTask, boolean core) {



• int wc = workerCountOf(c);


• if (wc >= (core ? corePoolSize : maximumPoolSize))


• // 如果当前活动线程数 >= 指定的核心线程数，不创建核心线程


• // 如果当前活动线程数 >= 指定的最大线程数，不创建非核心线程


• return false;



• boolean workerStarted = false;


• boolean workerAdded = false;


• Worker w = null;


• try {


• // 新建一个Worker，将要执行的任务作为参数传进去


• w = new Worker(firstTask);


• final Thread t = w.thread;


• if (t != null) {


• workers.add(w);


• workerAdded = true;


• if (workerAdded) {


• // 启动刚刚新建的那个worker持有的线程，等下要看看这个线程做了啥


• t.start();


• workerStarted = true;


• }


• }


• } finally {


• if (! workerStarted)


• addWorkerFailed(w);


• }


• return workerStarted;


• }2223242526272829303132



看到这里，我们大概能猜测到，addWorker方法的功能就是新建一个线程并启动这个线程，要执行的任务应该就是在这个线程中执行。为了证实我们的这种猜测需要再来看看Worker这个类。

• private final class Worker


• extends AbstractQueuedSynchronizer


• implements Runnable{


• // ....


• }



• Worker(Runnable firstTask) {


• setState(-1); // inhibit interrupts until runWorker


• this.firstTask = firstTask;


• this.thread = getThreadFactory().newThread(this);


• }123456789101112



从上面的Worker类的声明可以看到，它实现了Runnable接口，以及从它的构造方法中可以知道待执行的任务赋值给了它的变量firstTask，并以它自己为参数新建了一个线程赋值给它的变量thread，那么运行这个线程的时候其实就是执行Worker的run()方法，来看一下这个方法：

• public void run() {


• runWorker(this);


• }



• final void runWorker(Worker w) {


• Thread wt = Thread.currentThread();


• Runnable task = w.firstTask;


• w.firstTask = null;


• w.unlock(); // allow interrupts


• boolean completedAbruptly = true;


• try {


• while (task != null || (task = getTask()) != null) {


• w.lock();


• // If pool is stopping, ensure thread is interrupted;


• // if not, ensure thread is not interrupted. This


• // requires a recheck in second case to deal with


• // shutdownNow race while clearing interrupt


• if ((runStateAtLeast(ctl.get(), STOP) ||


• (Thread.interrupted() &&


• runStateAtLeast(ctl.get(), STOP))) &&


• !wt.isInterrupted())


• wt.interrupt();


• try {


• beforeExecute(wt, task);


• Throwable thrown = null;


• try {


• task.run();


• } catch (RuntimeException x) {


• thrown = x; throw x;


• } catch (Error x) {


• thrown = x; throw x;


• } catch (Throwable x) {


• thrown = x; throw new Error(x);


• } finally {


• afterExecute(task, thrown);


• }


• } finally {


• task = null;


• w.completedTasks++;


• w.unlock();


• }


• }


• completedAbruptly = false;


• } finally {


• processWorkerExit(w, completedAbruptly);


• }


• }04142434445464748



在run()方法中只调了一下 runWorker(this) 方法，再来简化一下这个 runWorker() 方法

• // 为分析而简化后的代码


• final void runWorker(Worker w) {


• Runnable task = w.firstTask;


• w.firstTask = null;


• while (task != null || (task = getTask()) != null) {


• try {


• task.run();


• } finally {


• task = null;


• }


• }


• }12345678910111213



很明显，runWorker()方法里面执行了我们新建Worker对象时传进去的待执行的任务，到这里为止貌似这个worker的run()方法就执行完了，既然执行完了那么这个线程也就没用了，只有等待虚拟机销毁了。那么回顾一下我们的目标：Java线程池中的核心线程是如何被重复利用的？好像并没有重复利用啊，新建一个线程，执行一个任务，然后就结束了，销毁了。没什么特别的啊，难道有什么地方漏掉了，被忽略了？再仔细看一下runWorker()方法的代码，有一个while循环，当执行完firstTask后task==null了，那么就会执行判断条件(task = getTask()) != null，我们假设这个条件成立的话，那么这个线程就不止只执行一个任务了，可以执行多个任务了，也就实现了重复利用了。答案呼之欲出了，接着看getTask()方法

• private Runnable getTask() {


• boolean timedOut = false; // Did the last poll() time out?



• for (;;) {


• int c = ctl.get();


• int rs = runStateOf(c);



• // Check if queue empty only if necessary.


• if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {


• decrementWorkerCount();


• return null;


• }



• int wc = workerCountOf(c);



• // Are workers subject to culling?


• boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;



• if ((wc > maximumPoolSize || (timed && timedOut))


• && (wc > 1 || workQueue.isEmpty())) {


• if ((c))


• return null;


• continue;


• }



• try {


• Runnable r = timed ?


• workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :


• workQueue.take();


• if (r != null)


• return r;


• timedOut = true;


• } catch (InterruptedException retry) {


• timedOut = false;


• }


• }


• }



老规矩，简化一下代码来看：

• // 为分析而简化后的代码


• private Runnable getTask() {


• boolean timedOut = false;


• for (;;) {


• int c = ctl.get();


• int wc = workerCountOf(c);



• // timed变量用于判断是否需要进行超时控制。


• // allowCoreThreadTimeOut默认是false，也就是核心线程不允许进行超时；


• // wc > corePoolSize，表示当前线程池中的线程数量大于核心线程数量；


• // 对于超过核心线程数量的这些线程，需要进行超时控制


• boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;



• if (timed && timedOut) {


• // 如果需要进行超时控制，且上次从缓存队列中获取任务时发生了超时，那么尝试将workerCount减1,即当前活动线程数减1，


• // 如果减1成功，则返回null，这就意味着runWorker()方法中的while循环会被退出，其对应的线程就要销毁了，也就是线程池中少了一个线程了


• if ((c))


• return null;


• continue;


• }



• try {


• Runnable r = timed ?


• workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :


• workQueue.take();



• // 注意workQueue中的poll()方法与take()方法的区别


• //poll方式取任务的特点是从缓存队列中取任务,最长等待keepAliveTime的时长，取不到返回null


• //take方式取任务的特点是从缓存队列中取任务，若队列为空,则进入阻塞状态，直到能取出对象为止



• if (r != null)


• return r;


• timedOut = true;


• } catch (InterruptedException retry) {


• timedOut = false;


• }


• }


• }39



从以上代码可以看出，getTask()的作用是

• 如果当前活动线程数大于核心线程数，当去缓存队列中取任务的时候，如果缓存队列中没任务了，则等待keepAliveTime的时长，此时还没任务就返回null，这就意味着runWorker()方法中的while循环会被退出，其对应的线程就要销毁了，也就是线程池中少了一个线程了。因此只要线程池中的线程数大于核心线程数就会这样一个一个地销毁这些多余的线程。

• 如果当前活动线程数小于等于核心线程数，同样也是去缓存队列中取任务，但当缓存队列中没任务了，就会进入阻塞状态，直到能取出任务为止，因此这个线程是处于阻塞状态的，并不会因为缓存队列中没有任务了而被销毁。这样就保证了线程池有N个线程是活的，可以随时处理任务，从而达到重复利用的目的。

小结

通过以上的分析，应该算是比较清楚地解答了“线程池中的核心线程是如何被重复利用的”这个问题，同时也对线程池的实现机制有了更进一步的理解：

• 当有新任务来的时候，先看看当前的线程数有没有超过核心线程数，如果没超过就直接新建一个线程来执行新的任务，如果超过了就看看缓存队列有没有满，没满就将新任务放进缓存队列中，满了就新建一个线程来执行新的任务，如果线程池中的线程数已经达到了指定的最大线程数了，那就根据相应的策略拒绝任务。

• 当缓存队列中的任务都执行完了的时候，线程池中的线程数如果大于核心线程数，就销毁多出来的线程，直到线程池中的线程数等于核心线程数。此时这些线程就不会被销毁了，它们一直处于阻塞状态，等待新的任务到来。

注意：
本文所说的“核心线程”、“非核心线程”是一个虚拟的概念，是为了方便描述而虚拟出来的概念，在代码中并没有哪个线程被标记为“核心线程”或“非核心线程”，所有线程都是一样的，只是当线程池中的线程多于指定的核心线程数量时，会将多出来的线程销毁掉，池中只保留指定个数的线程。那些被销毁的线程是随机的，可能是第一个创建的线程，也可能是最后一个创建的线程，或其它时候创建的线程。一开始我以为会有一些线程被标记为“核心线程”，而其它的则是“非核心线程”，在销毁多余线程的时候只销毁那些“非核心线程”，而“核心线程”不被销毁。这种理解是错误的。

另外还有一个重要的接口 BlockingQueue 值得去了解，它定义了一些入队出队同步操作的方法，还可以阻塞，作用很大。

❽ java 系统架构

开始的架构设计也是最难的，需要调研同类产品的情况以及技术特征，了解当前世界上对这种产品所能提供的理论支持和技术平台支持，再结合自己项目的特点(需要透彻的系统分析)，才能逐步形成自己项目的架构蓝图。
比如要开发网站引擎系统，就从Yahoo的个人主页生成工具 到虚拟主机商提供的网站自动生成系统，以及IBM Webphere Portal的特点和局限 从而从架构设计角度定立自己产品的位置。

好的设计肯定需要经过反复修改，从简单到复杂的循环测试是保证设计正确的一个好办法。

由于在开始选择了正确的方向，后来项目的实现过程也验证了这种选择，但在一些架构设计的细部方面，还需要对方案进行修改，属于那种螺旋上升的方式，显然这是通过测试第一的思想和XP工程方法来实现的。

如果我们开始的架构设计在技术平台定位具有一定的世界先进水平，那么，项目开发实际有一半相当于做实验，是研发，存在相当的技术风险。

因此，一开始我们不可能将每个需求都实现，而是采取一种简单完成架构流程的办法，使用最简单的需求将整个架构都简单的完成一遍(加入人工干 预)，以检验各个技术环节是否能协调配合工作(非常优秀先进的两种技术有时无法在一起工作)，同时也可以探知技术的深浅，掌握项目中的技术难易点。这个过 程完成后，我们就对设计方案做出上面的重大修改，丰富完善了设计方案。

设计模式是支撑架构的重要组件

架构设计也类似一种工作流，它是动态的，这点不象建筑设计那样，一开始就能完全确定，架构设计伴随着整个项目的进行过程之中，有两种具体操作保证架构设计的正确完成，那就是设计模式(静态)和工程项目方法(RUP或XP 动态的)。

设计模式是支撑架构的一种重要组件，这与建筑有很相象的地方，一个建筑物建立设计需要建筑架构设计，在具体施工中，有很多建筑方面的规则和模式。

我们从J2EE蓝图模式分类http://java.sun.com/blueprints/patterns/catalog.html中就可以很清楚的看到J2EE这样一个框架软件的架构与设计模式的关系。

架构设计是骨架，设计模式就是肉

这样，一个比较丰富的设计方案可以交由程序员进一步完成了，载辅助以适当的工程方法，这样就可保证项目的架构设计能正确快速的完成。

时刻牢记架构设计的目标

由于架构设计是在动态中完成的，因此在把握架构设计的目标上就很重要，因此在整个项目过程中，甚至每一步我们都必须牢记我们架构设计的总体目标，可以概括下面几点：

1. 最大化的重用：这个重用包括组件重用 和设计模式使用等多个方面。

比如，我们项目中有用户注册和用户权限系统验证，这其实是个通用课题，每个项目只是有其内容和一些细微的差别，如果我们之前有这方面成功研发经 验，可以直接重用，如果没有，那么我们就要进行这个子项目的研发，在研发过程中，不能仅仅看到这个项目的需求，也要以架构的概念去完成这个可以称为组件的 子项目。

2. 尽可能的简单明了：我们解决问题的总方向是将复杂问题简单化，其实这也是中间件或多层体系技术的根本目标。但是在具体实施设计过程中，我们可能会将简单问题复杂化，特别是设计模式的运用上很容易范这个错误，因此如何尽可能的做到设计的简单明了是不容易的。

我认为落实到每个类的具体实现上要真正能体现系统事物的本质特征，因为事物的本质特征只有一个，你的代码越接近它，表示你的设计就是简单明了， 越简单明了，你的系统就越可靠。更多情况是，一个类并不能反应事物本质，需要多个类的组合协调，那么能够正确使用合适的设计模式就称为重中之重。

我们看一个具备好的架构设计的系统代码时，基本看到的都是设计模式，宠物店(pet store)就是这样的例子。或者可以这样说，一个好的架构设计基本是由简单明了的多个设计模式完成的。

3. 最灵活的拓展性：架构设计要具备灵活性 拓展性，这样，用户可以在你的架构上进行二次开发或更加具体的开发。

要具备灵活的拓展性，就要站在理论的高度去进行架构设计，比如现在工作流概念逐步流行，因为我们具体很多实践项目中都有工作流的影子，工作流中有一个树形结构权限设定的概念就对很多领域比较通用。

树形结构是组织信息的基本形式，我们现在看到的网站或者ERP前台都是以树形菜单来组织功能的，那么我们在进行架构设计时，就可以将树形结构和 功能分开设计，他们之间联系可以通过树形结构的节点link在一起，就象我们可以在圣诞树的树枝上挂各种小礼品一样，这些小礼品就是我们要实现的各种功 能。

有了这个概念，通常比较难实现的用户级别权限控制也有了思路，将具体用户或组也是和树形结构的节点link在一起，这样就间接实现了用户对相应功能的权限控制，有了这样的基本设计方案的架构无疑具备很灵活的拓展性。

Java架构设计

软件架构作为一个概念，体现在技术和业务两个方面。

从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。

先说一些基本原则：

分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。
模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。
接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。从这个原则出发，软件也从微观进行了细致的规范化。

还有两个比较小但很重要的原则：

细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade(外观)模式就很能体现这个原则的精神。

依赖倒置原则随着软件结构的进一步发展,层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。依赖倒置原则可看视 为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。这个原则有点类似于知名的好莱坞法则：Don't call us, we'll call you。

以上这些原则奠定了我们的软件架构的价值指标。但软件架构毕竟是建立在当前技术之上的。而每一代技术都有架构模式。过去的不再说了，让我们现在就来看一下当前流行的技术，以及当前我们能采用的架构。

因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用 户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。我们从三层 次架构谈起：

因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实 现技术。cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能 相当完备。推荐作为持久层的首选

在业务层,因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。

在用户结构层,虽然servlet/jsp/jstl/javaBean 能够实现MVC架构,但终究过于粗糙。struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非 常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。

因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致 性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务 (tool:jaas)、流程控制服务workflow、动态实现服务IOC，串行化消息服务(tool:jms)、负载平衡服务blance等。如果我 们不采用重量级应用服务器(如weblogic,websphere,jboss等)及重量级组件(EJB)，我们必须自己实现其中一些服务。虽然我们大 多情况下，不需要所有这些服务，但实现起来却非易事。幸运的是我们有大量的开源实现代码,但采用开源代码却常常是件不轻松的事。

随着xml作为结构化信息传输和存储地位日渐重要,一些xml文档操作工具(DOM,Digester,SAX等)的使用愈发重要,而随着 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，采用xml schema来设计xml文档格式,然后采用java binding来生成java bean 会成为主要编程模式,而这又进一步使数据中心向xml转移,使在中小数据量上,愈发倾向于以xquery为查询语言的xml数据库。最近还有一个趋势, microsoft,ibm等纷纷大量开发中间软件如(microsoft office之infopath)，可以直接从xml schema 生成 录入页面等非常实用的功能。还有web service 的广泛应用，都将对软件的架构有非常重大的影响。至于面向服务架构(SOA)前景如何，三层次架构什么时候走入历史，现在还很难定论。

aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、 nanning都有其自身的严重问题:维护性很差,所以说它将很难走远。也许作为一个很好的思想，它将在web service里大展身手。

rdf,owl作为w3c语义模型的标志性的语言,也很难想象能在当前业务架构发挥太大影响。但如果真如它所声称那样，广泛地改变着信息的结构。那么对软件架构也会有深远影响。

有关架构设计的一些忠告：

尽量建立完整的持久对象层.可获得高回报
尽量将各功能分层,分块,每一模块均依赖假定的其它模块的外观
不能依赖静态数据来实现IOC模式，应该依赖数据特征接口，静态数据仅是数据特征接口实现方式之一
架构设计时xml是支持而不是依赖.但可以提供单一的xml版本的实现

从业务角度说：软件架构应是深刻体现业务内部规则的业务架构，但因为业务变化频纴，所以软件架构很难保持恒定不变，但业务的频繁变化不应是软件架构大规模频繁变化的原因，软件架构应是基于变化的架构。

一种业务有其在一段时间内稳定存在的理由(暂且不谈)，业务内部有许多用例，每一种用例都有固定的规则，每一规则都有一些可供判定的项，每一项 从某一维度来观察都是可测量的，我们的架构首先必须保证完美适应每一项每一种测量方式，很多失败的架构都是因为很多项的测量方式都发生变更这种微观变化 中。

每个用例都有规则，我们在作业务用例分析，常常假定一些规则是先验的，持久稳定的，然而后来的业务改变常常又证明这种看法是错误的，然而常常我 们的架构已经为之付出了不可挽回的代价。大量事实证明：规则的变化常常用例变化的根本原因。所以我们的架构要尽可能适应规则的变化，尽可能建立规则模版。

每个用例都关系着不同的角色。每一个用例的产生都必然是因为角色的变更(注意：不是替换，而是增强或减弱)，所以注意角色的各种可能情况，对架构的设计有举足轻重的意义。在我们当前的三层架构里，角色完美地对应接口概念。

在一个系统里很多用例都相互关联,考虑到每个用例均有可能有不同的特例，所以在架构设计中，尽量采用依赖倒置原则。如架构许可可采用消息通信模式(JMS)。这样可降低耦合度。

现在我们谈一下业务稳定存在理由对业务的影响。存在即是合理，在这里当然是正确的。业务因人而存在，所以问业务存在的理由即是问不同角色的需要这项业务的理由以及喜欢不喜欢当前业务用例的理由，所有这样的角色都应该在系统里预留。

在架构设计中有几个原则可以考虑：

用例尽量细分
用例尽量抽象
角色尽量独立
项测量独立原则
追求简单性
这里未提供相关的例子，例子会在以后的更新时提供。

业务和模式之间的关系

业务中的一些用例之间的关系常常和一些常规的模式很相似。但随着时间的演化，慢慢地和先前的模式有了分歧。这是个正常的现象。但这对系统架构却要求非常高，要求系统架构能适应一些模式的更替。在这里我们尽可能早地注意到用例之间的相互角色变化，为架构更新做好准备.

❾ java中的修饰符

static 表示静态，它可以修饰属性，方法和代码块。

1，static修饰属性（类变量），那么这个属性就可以用 类名.属性名 来访问，也就是使这个属性成为本类的类变量，为本类对象所共有。这个属性就是全类公有。（共有的类变量与对象无关，只和类有关）。

类加载的过程，类本身也是保存在文件中（字节码文件保存着类的信息）的，java会通过I/O流把类的文件（字节码文件）读入JVM（java虚拟机），这个过程成为类的加载。JVM（java虚拟机）会通过类路径（CLASSPATH）来找字节码文件。

类变量，会在加载时自动初始化，初始化规则和实例变量相同。

注意：类中的实例变量是在创建对象时被初始化的，被static修饰的属性，也就是类变量，是在类加载时被创建并进行初始化，类加载的过程是进行一次。也就是类变量只会被创建一次。

2，static修饰方法（静态方法），会使这个方法成为整个类所公有的方法，可以用类名.方法名 访问。

注意：static修饰的方法，不直接能访问（可以通过组合方式访问）本类中的非静态(static)成员（包括方法和属性），本类的非静态（static）方法可以访问本类的静态成员（包括方法和属性），可以调用静态方法。静态方法要慎重使用。在静态方法中不能出现this关键字。

注意：父类中是静态方法，子类中不能覆盖为非静态方法，在符合覆盖规则的前提下，在父子类中，父类中的静态方法可以被子类中的静态方法覆盖，但是没有多态。（在使用对象调用静态方法是其实是调用编译时类型的静态方法）

注意：父子类中，静态方法只能被静态方法覆盖，父子类中，非静态方法只能被非静态方法覆盖。

java中的main方法必须写成static的因为，在类加载时无法创建对象，因为静态方法可以不通过对象调用
所以在类的main方法。所在在类加载时就可以通过main方法入口来运行程序。

注意：组合方式，就是需要在方法中创建一个所需要的对象，并用这个对象来调用任意所需的该对象的内容，不会再受只能访问静态的约束。

3，static修饰初始代码块，这时这个初始代码块就叫做静态初始代码块，这个代码块只在类加载时被执行一次。可以用静态初始代码块初始化一个类。

动态初始代码块，写在类体中的“{}”，这个代码块是在生成对象的初始化属性是运行。这种代码块叫动态初始代码块。

类在什么时候会被加载，构造（创建）对象时会加载类，调用类中静态方法或访问静态属性也是会加载这个静态方法真正所在的类。在构造子类对象时必会先加载父类，类加载会有延迟加载原则，只有在必须加载时才会加载。

final修饰符，可以修饰变量，方法，类

1,final修饰变量
被fianl修饰的变量就会变成常量（常量应当大写），一旦赋值不能改变，（可以在初始化时直接赋值，也可以在构造方法里也可以赋值，只能在这两种方法里二选一，不能不为常量赋值），fianl的常量不会有默认初始值，对于直接在初始化是赋值时final修饰符常和static修饰符一起使用。

2，final修饰方法，被final修饰的方法将不能被其子类覆盖，保持方法的稳定不能被覆盖。
3，final修饰类，被final修饰的类将不能被继承。final类中的方法也都是final的。

注意：final，不能用来修饰构造方法，在父类中如果有常量属性，在子类中使用常量属性时是不会进行父类的类加载。静态常量如果其值可以确定，就不会加载该类，如果不能确定则会加载该常量所在的类。

不变模式，对象一旦创建属性就不会改变。用final修饰属性，也用final修饰类（强不变模式），用final修饰属性（弱不变模式）。

不变模式的典型体现：java.lang.String类，不变模式可以实现对象的共享（可以用一个对象实例赋值给多个对象变量。）

池化的思想，把需要共享的数据放在池中（节省空间，共享数据）
只有String类可以用“”中的字面值创建对象。在String类中，以字面值创建时，会到Java方法空间的串池空间中去查找，如果有就返回串池中字符串的地址，并把这个地址付给对象变量。如果没有则会在串池里创建一个字符串对象，并返回其地址付购对象变量，当另一个以字面值创建对象时则会重复上述过程。
如果是new在堆空间中创建String类的对象，则不会有上述的过程。

String类中的intern()方法会将在堆空间中创建的String类对象中的字符串和串池中的比对，如果有相同的串就返回这个串的串池中的地址。

不变模式在对于对象进行修改，添加操作是使相当麻烦的，他会产生很多的中间垃圾对象。创建和销毁的资源的开销是相当大的。

String类在字符串连接时会先的效率很低，就是因为它所产生的对象的书性是不能够修改的，当连接字符串时也就是只能创建新的对象。

对于很多的字符串连接，应当使用StringBuffer类，在使用这个类的对象来进行字符串连接时就不会有多余的中间对象生成，从而优化了效率。

abstract（抽象）修饰符，可以修饰类和方法

1，abstract修饰类，会使这个类成为一个抽象类，这个类将不能生成对象实例，但可以做为对象变量声明的类型，也就是编译时类型，抽象类就像当于一类的半成品，需要子类继承并覆盖其中的抽象方法。

2，abstract修饰方法，会使这个方法变成抽象方法，也就是只有声明（定义）而没有实现，实现部分以";"代替。需要子类继承实现（覆盖）。

注意：有抽象方法的类一定是抽象类。但是抽象类中不一定都是抽象方法，也可以全是具体方法。
abstract修饰符在修饰类时必须放在类名前。

abstract修饰方法就是要求其子类覆盖（实现）这个方法。调用时可以以多态方式调用子类覆盖（实现）后的方法，也就是说抽象方法必须在其子类中实现，除非子类本身也是抽象类。

注意：父类是抽象类，其中有抽象方法，那么子类继承父类，并把父类中的所有抽象方法都实现（覆盖）了，子类才有创建对象的实例的能力，否则子类也必须是抽象类。抽象类中可以有构造方法，是子类在构造子类对象时需要调用的父类（抽象类）的构造方法。

final和abstract，private和abstract，static和abstract，这些是不能放在一起的修饰符，因为abstract修饰的方法是必须在其子类中实现（覆盖），才能以多态方式调用，以上修饰符在修饰方法时期子类都覆盖不了这个方法，final是不可以覆盖，private是不能够继承到子类，所以也就不能覆盖，static是可以覆盖的，但是在调用时会调用编译时类型的方法，因为调用的是父类的方法，而父类的方法又是抽象的方法，又不能够调用，所以上的修饰符不能放在一起。

抽象（abstract）方法代表了某种标准，定义标准，定义功能，在子类中去实现功能（子类继承了父类并需要给出从父类继承的抽象方法的实现）。
方法一时间想不到怎么被实现，或有意要子类去实现而定义某种标准，这个方法可以被定义为抽象。(abstract)

模板方法模式

用abstract把制订标准和实现标准分开，制定的标准就是模板，实现就是按模板标准来实现，也就是继承模板，实现模板中相应功能的方法。模板中不允许修改的方法可以用fianl来修饰，这个方法不能使抽象方法，为保证安全，封装，把模板中不公开的部分用protected（保护）修饰。