#
Tomcat5集群中的SESSION复制
Tomcat 5服务器为集群和SESSION复制提供了集成的支持。本系列的第一篇文章将为大家提供SESSION持久性以及TOMCAT集群中SESSION复制的内在工作机制一个概要认识。我将会讨论SESSION复制在TOMCAT5中是怎样进行的以及跨越多集群节点的SESSION持久性的复制机制。在第2部分，我会详细讨论一个带有SESSION复制功能的TOMCAT集群的安装例子，并且比较不同的复制情形。
集群
传统独立服务器（非集群的）不提供任何失效无缝转移以及负载平衡能力。当服务器失败的时候，就无法获取整个网站的内容，除非服务器被重新唤起。由于服务器失效，任何存储在服务器内存中的SESSION都会丢失，用户必须重新登陆并且输入所有由于服务器失效丢失的数据。
不同的是，作为集群一部分的服务器则提供了可测性以及失效无缝转移能力。一个集群就是一组同步运行并且协同工作，能提供高可靠性，高稳定性以及高可测性的多服务器例程。服务端集群对客户端表现出来似乎就是一个单独的服务器例程。从客户端的视角来看，集群的客户端和单独的服务器没多大不同，但是他们通过提供实效无缝转移和SESSION复制做到了不间断服务以及SESSION数据持久性。
集群中的服务器通讯
集群中的应用程序服务器通过诸如IP多点传送（IP multicast）和IP sockets这样的技术和其他服务器共享信息
●IP多点传送：主要用于1对多的服务器通讯，通过广播服务和 heartbeats消息的可用来显示服务器的有效
●IP sockets：主要用于在集群的服务器例程中进行P2P服务器通讯
使用ip多点传送进行一对多通讯
TOMCAT服务器使用IP多点传送在集群中的服务器例程间进行一对多的通讯，IP多点传送是一种能够让多服务器向指定IP地址和端口号进行订阅并且监听消息的广播技术（多点传送IP地址范围从224.0.0.0 到239.255.255.255）。在集群中的每个服务器都使用多点传送广播特定的 heartbeat消息，通过监视这些 heartbeat消息，在集群中的服务器例程判断什么时候服务器例程失效。在服务器通讯中使用IP多点传送的一个缺点是他不能保证这些消息被确实接收到了。例如，一个应用持续的本地多点传送缓存满了，就不能写入新的多点传送消息，等消息过了之后该应用程序就没有被通知到。
使用ip Sockets进行服务器通讯
IP sockets 同样也通过了一套在集群中的服务器间进行发送消息和数据的机制。服务器例程使用IP sockets 在集群节点间进行HTTP SESSION状态的复制。正确的SOKET配制对于集群的性能是至关重要的，基于SOCKET的通讯的效率取决于SOCKET的实现类别（例如：系统使用本地的或者纯JAVA SOCKET读取器实现），如果服务器使用纯JAVA SOCKET读取器则要看服务器例程是否注册使用了足够的SOCKET读取器线程。
如果想要有最佳的SOCKET性能，系统应该注册使用本地的SOCEKT而不是纯JAVA实现。这是因为相对于基于JAVA的SOCKET实现，本地SOCKET消耗更少的系统资源。虽然SOCKET读取器的JAVA实现是P2P通信中一种可靠而且可移动的方法，可是他不能为集群中的重型SOCKET使用提供最好的性能。当判断从SOCKET是否有数据读取的时候本地SOCKET读取器使用了更有效率的方法。使用本地SOCKET读取器实现，读取器线程不需要去统计静止的SOCKET：他们仅仅为活动的SOCKET服务，并且在一个给定的SOCKET开始活跃起来时他们可以立刻捕捉到。而使用纯JAVA SOCKET读取器，线程必须动态的统计所有打开的SOCKET，判断他们是否包含可读取的数据。换句话说，SOCKET读取器总是忙于统计SOCKET，即使这些SOCKET没有数据可读。这些本不应该的系统开销降低了性能。
TOMCAT 5中的集群
虽然在TOMCAT5的早些版本中也有集群的功能，但是在稍后的版本中（5.0.19或者更高），集群变的更加模块组件化。在 server.XML 中集群元素已经被重构，这样我们可以替换集群的不同部分而不会影响其他元素。例如，当前配置中把成员服务设置为多点传送发现。这里可以轻易地把成员服务修改替换为使用TCP或者 Unicast ，而不会改变集类逻辑的其他部分。
其他一些集群元素，例如SESSION管理器，复制发送端，复制接受端也可以被自定义的实现取代而不影响集群配置的其他部分。同样，在TOMCAT集群中的任何服务器组件可以使用集类API向集群中的所有成员发送消息。
SESSION复制
服务器集群通常操纵两种SESSION： sticky sessions和 replicated sessions .sticky sessions就是存在单机服务器中的接受网络请求的SESSION，其他集群成员对该服务器的SESSION状态完全不清楚，如果存有SESSION的服务器失败的话，用户必须再次登陆网站，重新输入所有存储在SESSION中的数据。
另一种SESSION类型是，在一台服务器中SESSION状态被复制到集群中的其他所有服务器上，无论何时，只要SESSION 被改变，SESSION数据都要重新被复制。这就是 replicated session . sticky 和 replicated sessions都有他们的优缺点， Sticky sessions简单而又容易操作，因为我们不必复制任何SESSION数据到其他服务器上。这样就会减少系统消耗，提高性能。但是如果服务器失败，所有存储在该服务器内存中的SESSION数据也同样会消失。如果SESSION数据没有被复制到其他服务器，这些SESSION就完全丢失了。当我们在进行一个查询事务当中的时候，丢失所有已经输入的数据，就会导致很多问题。
为了支持 jsp HTTP session 状态的自动失效无缝转移，TOMCAT服务器复制了在内存中的SESSION状态。这是通过复制存储在一台服务器上的SESSION数据到集群中其他成员上防止数据丢失以及允许失效无缝转移。
对象的状态管理
通过在服务器上的保存状态可以区分出4种对象：
●无状态：一个无状态对象在调用的时候不会在内存中保存任何状态，因为客户端和服务器端没必要保存任何有关对方的信息。在这种情况下，客户端会在每次请求服务器时都会发送数据给服务器。SESSION状态被在客户端和服务器端来回发送。这种方法不总是可行和理想的，特别是当传输的数据比较大或者一些安全信息我们不想保存在客户端的时候；
●会话：一个会话对象在一个SESSION中只被用于特定的某个客户端。在SESSION中，他可以为所有来自该客户端的请求服务，并且仅仅是这个客户端的请求。贯穿一个SESSION，两个请求间的状态信息必须保存。会话服务通常在内存中保存短暂的状态，当在服务器失败的时候可能会丢失。SESSION状态通常被保存在请求间的服务器的内存中。为了清空内存，SESSION状态也可以被从内存中释放（就像在一个对象CACHE）。在该对象中，性能和可量测性都有待提高，因为更新并不是被单独的写到磁盘上，并且服务器失败的时候数据也没办法抢救。
●缓存：缓存对象在内存中保存状态，并且使用这个去处理从多客户端来的请求。缓存服务的实现可以扩展到他们把缓存的是数据备份保存在后端存储器中（通常是一个关系数据库）。
●独立的：一个独立的对象在一个时间内只活跃在集群中的一台服务器上，处理来自多客户端的请求。他通常由那些私有的，持久的，在内存中缓寸的数据支持。他同样也在内存中保持短暂状态，在服务器失败的时候要重建或者丢失。当失败的时候，独立对象必须在同一个服务器上重起或者移植到另一台服务器上。
SESSION复制的设计考虑事项
网络考虑事项
把集群的多点传送地址和其他应用程序隔离是至关重要的。我们不希望集群配置或者网络布局干扰到多点传送服务器通信。和其他应用程序共享集群多点传送地址将迫使集群的服务器例程处理不应该的消息，消耗系统内存。共享多点传送地址可能也会使IP多点传送缓冲过载，延迟服务器 heartbeat 消息传输。这样的延迟可能导致一个服务器例程被标识为死亡，仅仅因为他的 heartbeat 消息没有被及时接收。
编程考虑事项
除了上面提到的网络相关因素，还有些和我们写 J2EE 网络应用程序有关的设计考虑也会影响SESSION复制。以下列出了一些编程方面的考虑：
●SESSION数据必须被序列化：为了支持HTTP session 状态的内存内复制，所有的 servlet 和 JSP session 数据必须被序列化，对象中的每个域都必须被序列化，这样对象被可靠的序列化。
●把应用程序设计为幂等的：幂等的的意思就是一个操做不会修改状态信息，并且每次操作的时候都返回同样的结果（换句话说就是：做多次和做一次的效果是一样的），通常，WEB请求，特别是 HTML forms 都被发送多次（当用户点击发送按纽两次，重载页面多次），导致多次HTTP请求。设计SERVLET和其他WEB对象为 幂等的，可以容忍多次请求。详细可以去参考设计模式“Synchronized Token ”和“Idempotent Receiver ”关于怎样设计幂等的的应用程序。
●在BUSINESS层存储状态：会话状态应该使用有状态的SESSION BEANS存储在EJB层，而不是存储在WEB层的HttpSession.因为企业应用程序要支持各种类型客户端（WEB客户端，JAVA应用程序，其他EJB），存储数据在WEB层会导致在客户端的双数据存储。因此，有状态的SESSION BEAN在这些情况下就被用于存储SESSION状态。无状态的SESSION BEAN要为每次的调用重构造会话状态。这些状态可能必须从数据库中恢复的数据中重编译。这些缺点失去了使用无状态SESSION BEAN去提高性能和可测量性的目的，严重的减低了性能。
●序列化系统消耗：序列化SESSION数据在复制SESSION状态的时候回会些系统消耗。随着序列化对象大小的增长消耗也越多。最好是保持SESSION容量适当的小。但是如果你必须在SESSION中创建非常大的对象，最好测试下你的 servlets 性能以保证性能是可接受的以及SESSION的复制时间是适当的。
●用户SESSION：判断在集群中每个TOMCAT服务器例程所控制的并发用户SESSION最大数是很重要的。为了控制更多并发SESSION，我们应该为提高效率添加更多内存。最大并发客户端数，以及每个客户端请求的频率在决定SESSION复制对服务器的性能影响方面也是个因素。
Tomcat 5中的SESSION复制
在版本5之前，TOMCAT服务器只支持sticky sessions （使用mod_jk模块进行负载平衡）。如果我们需要SESSION复制，必须依靠第3方软件例如JavaGroups 去实现。
Tomcat 5服务器带有SESSION复制功能。和集群特征类似，只要修改 server.xml 注册文件就能实现SESSION复制。
Martin Fowler 在他的书《 Enterprise Patterns》中谈到三个SESSION状态持久性模式，这些模式包括：
1.客户端SESSION状态：在客户端存储SESSION状态
2.服务端SESSION状态：在一个序列化的FORM中保持SESSION状态到一个服务器系统上。
3.数据库SESSION状态：当在数据库中提交数据的时候存储SESSION数据。
TOMCAT支持以下三种SESSION持久性类型：
1.内存复制：在JVM内存中复制SESSION状态，使用TOMCAT 5安装带的SimpleTcpCluster 和 SimpleTcpClusterManager 类。这些类在包org.apache.catalina.cluster中，是server/lib/catalina-cluster.jar的一部分。
2.数据库持久性：在这种类型中，SESSION状态保存在一个关系数据库中，服务器使用JDBCManager类从数据库中获取SESSION信息。这个类在包org.apache.catalina.session.JDBCStore中，是catalina.jar的一部分。
3.基于文件的持久性：这里使用类PersistenceManager把SESSION状态保存到一个文件系统。这个类在包org.apache.catalina.session.FileStore中，是catalina.jar的一部分。
TOMCAT集群元素以及SESSION复制这章简要介绍一下组成TOMCAT集群的元素以及SESSION复制。
集群：
这个是集群中的主要元素， SimpleTcpCluster类代表这个元素。他使用在server.xml中指定的管理类为所有可分配的web contexts生成ClusterManager.
集群管理器
这个类关注跨越集群中所有节点间的SESSION数据复制。所有在web.xml文件中指定了distributable标记的WEB应用程序都会有SESSION复制。集群管理器作为集群元素的managerClassName属性在server.xml中指定。集群管理器的代码主要被设计用来分离集群中的元素。我们所要做的就是写一个SESSION管理器类去实现ClusterManager接口。这样能让我们灵活的使用客户集群管理器而不会影响到集群中的其他元素。这里有两个复制算法。SimpleTcpReplicationManager每次复制全部的SESSION，而DeltaManager只复制SESSION增量。
最简单的复制管理器在每次HTTP请求都复制所有的SESSION.在SESSION较小的时候这样是很有用的，我们可以只用以下代码：
HashMap map = session.getAttribute（"map"）；map.put（"data"，"data"）；
这里，我们不需要特别调用session.setAttribute（） 或者 removeAttribute方法去复制SESSION变化。对于每次HTTP请求，在SESSION中的所有属性都被复制。可以使用一个叫做useDirtyFlag的属性去最优化SESSION被复制的次数。如果这个标记被设为真，我们必须调用setAttribute（）方法去获取被复制的SESSION变化。如果被设为假，每次请求后SESSION都被复制。
SimpleTcpReplicationManager生成ReplicatedSession执行SESSION复制工作。
提供增量管理器仅仅是为了性能的考虑。它在每次请求的时候都做一次复制。同时他也调用监听器，所以如果我们调用session.setAttribute（），那么在其他服务器上的监听器就会被调用。DeltaManager生成DeltaSession执行 SESSION复制。
成员成员的建立通过由TOMCAT例程在同样的多点传送IP和端口发送广播消息。广播的消息包括服务器的IP地址和TCP监听端口（默认IP地址为228.0.0.4）。
如果在给定的时间框架内一个例程没有接收到消息（由集群配置中的mcastDropTime参数指定），成员被认为死亡。这个元素由McastService类表示。
由mcastXXX开始的属性用于成员资格多点传送PING.以下表格列出了用于IP多点传送服务器通讯的属性。
发送端
这个元素由ReplicationTransmitter类代表。当多点传送广播消息被接收到，成员被添加到机群。在下次复制请求前，发送例程将使用主机和端口信息建立一个TCP SOCKET.使用这些SOCKET发送序列化的数据。在TOMCAT 5中有3种不同的方法操纵SESSION复制：异步，同步，池复制模式。以下部分解释了这些模式怎样工作，以及他们将被使用在什么情况下。
●异步：在这种复制模式中，每个集群节点都有一个单线程扮演SESSION数据传送器。这里，请求线程会把复制请求发送到一个队列，然后返回给客户端。在失效无缝转移前，如果我们拥有sticky sessions，就应该使用异步复制。这里复制时间不是至关重要的，但是请求时间却是。在异步复制期间，请求在数据被复制完之前就返回了。这种复制模式缩短了请求时间。当每个请求被分的更开这种模式是很有用的。（例如，在WEB请求间有更长的延迟）。同样，如果我们不关心SESSION是否完成复制这个也很有用，当SESSION很较小时， SESSION复制时间也更短。
●同步：在这种模式中，一个单线程执行了HTTP请求和数据复制。集群中所有节点都接收到SESSION数据后线程才返回。同步意味被被复制的数据通过一个单SOCKET发送。由于使用一个单线程，同步模式可能会是簇性能的一个潜在的瓶颈。这种复制模式保证了在请求返回前SESSION 已经被复制。
●池：TOMCAT5 在使用池复制模式进行SESSION复制的方法上提供了很大的改进。
池模式基本上是同步模式的一个扩展版本。他基于的一个原则是：划分服务到多例程，每个例程处理不同的SESSION数据片段。同时对接收服务器开放多SOCKET进行发送SESSION信息。这种方法比通过单SOCKET发送所有东西更快。因此，使用一个SOCKET池同步复制SESSION.直到所有SESSION数据都复制完请求才返回。为了有效使用这种模式要增加TCP线程。由于使用多SOCKET，池模式使得集群性能的逐步提高以及更好的可测性。同样这种模式也是最安全的配置，因为它有足够数量的SOCKET在理想的时间内发送所有的SESSION数据到其他节点上。而使用单SOCKET，SESSION数据在通过集群时可能丢失或者只是部分传输。
接收端
这个集群元素由类ReplicationListener表示。在集群配置中以tcpXXX开始的属性用于TCP SESSION复制。以下表格列出了用于配置服务器复制中基于SOCEKT服务器通讯的属性。
复制值
复制值用于判断哪些HTTP请求需要被复制。由于我们不经常复制静态内容（例如HTML和javascript， stylesheets，图像文件），我们可以使用复制值元素过滤掉静态内容。这个值可以用于找出什么时候请求已完成以及初始化复制。
部署器
部署器元素可以用于部署集群范围的应用程序。通常，部署只部署/解除部署簇内的工作成员。所以在损坏的节点在启动时没有WARS的复制。当watchEnabled="true"时配置器为WAR文件监视一个目录（watchDir）。当添加一个新的WAR文件时，WAR被部署到本地例程，然后被部署到集群中的其他例程。当一个WAR文件从watchDir删除，这个WAR被从本地和集群范围内解除部署。
所有在TOMCAT集群结构中的元素以及他们的层次关系都在列在图1中
图 1. Tomcat 集群等级结构图。单击看原图。
TOMCAT中SESSION复制是怎么工作的
以下部分简要解释当TOMCAT服务器启动或则关闭时集群节点怎样分享SESSION信息，详细信息可参考Tomcat 5 Clustering文挡。
TC-01：集群中第一个节点TC-02：集群中第2个节点
●服务器启动：TC-01使用标准服务器启动队列启动。当主机对象被创建，即有一个集群对象和它相关联。当contexts被解析，如果distributable已经在web.xml中指定，那么TOMCAT为WEB CONTEXT创建SESSION管理器（SimpleTcpReplicationManager 取代StandardManager）。集群将会启动一个成员服务（成员的一个例程）和一个复制服务。
当TC-02启动，他也遵循第一个成员（TC-01）同样的队列但是有一个不同。集群被启动并且创建一个成员关系（TC-01，TC-02）。TC-02将向TC-01请求SESSION状态。TC-01回应该请求，在TC-2开始监听HTTP请求前，TC-01发送状态给TC-02.如果TC-01不回应，TC-02将在60秒后进入中止状态并且发布一个日志入口。SESSIONG 状态发送给所有在web.xml中指定了distributable的WEB应用程序。
●创建SESSION：当TC-01接收到请求，一个SESSION（S1）被创建，处理进入TC-01的请求和没有SESSION复制时是一样的。当请求完成时会有以下事件：ReplicationValve将会在回应返回给用户前截取请求。这里，会发现SESSION已经被改变，使用TCP复制SESSION到TC-02.●服务器储运损耗/关闭：当在集群中的一台服务器失败，维护损坏或者系统升级，其他节点会受到第一个节点已经脱离集群的通知。TC-02从他的成员资格列删除TC-01，并且TC-02在也不会收到有关TC-01任何变动的通知。负载平衡将会移至TC-02，所有的SESSION由TC-02控制。
当TC-01开始恢复，他再次遵循在服务器开始阶段描述的启动队列。加入到簇中并且以所有SESSIONG的当前状态和TC-02通讯。一旦接收到 SESSIONG状态，也就完成了加载然后打开它的HTTP/ mod_jk端口。所以，要等到从TC-2接受到SESSION状态TC-01才能发送请求。
●SESSION终止：如果在第一个节点的一个SESSION已经无效或则由于过期终止，无效请求将被截取，SESSION会被同其他无效SESSION放在一个队列中。当请求完成，服务器发送SESSIONG终止消息给TC-02而不是发送已经改变的SESSION，TC-02同样也会把该SESSION置无效。我们可以从服务器控制台看到SESSIONG无效的消息。无效SESSION在集群中将不会被复制，直到其他请求传出系统并且检查无效队列。
我的一个客户不知道该选用Struts还是JSF。就像你预料的那样，我通常会问：这2中框架之间有什么区别？当然，除了我的这个客户外很多人都面临这样的选择。
总的来说，我建议在新项目中优先考虑JSF。虽然常常有一些商业上的因素迫使我们为现有的项目选择了Struts，而且那些解决方案还有待考验，但是，让我们面对一个事实：JSF比Struts好多了。
下面是我选择JSF而不选Struts的十大理由：
1.Components(组件)
2.Render Kits
3.Renderers
4.Value Binding Expressions（值绑定表达式）
5.Event Model（事件模型）
6.Extensibility(可扩展性)
7.Managed Beans(Dependency Injection 依赖注入)
8.POJO Action Methods
9.JSF is the standard Java-based web app framework (JSF是java web应用程序的标准框架)
10.There's only one Struts(只有一个Struts)
10.There's only one Struts(只有一个Struts)
Struts是一个开源产品，然而JSF是一个标准。这个细节常常被新的JSF学习者忽略，其实这是显而易见的，因为我们有多个JSF的实现。虽然JSF还很不成熟，但是我们已经有了2个优秀的JSF实现可以选择：Sun的参考实现和Apache的MyFaces。另一方面，我们只有一个Struts。
9.JSF is the standard(JSF是标准)
JEE 5.0要提供一个JSF的实现，这表明JSF不久将会无处不在。这可能与你无关，但是和工具供应商密切相关。现在大概有50个java web应用程序框架，工具供应商不会情愿去支持一个特别的框架，但是他们会毫不犹豫的去支持一个卫星电视器材标准。而且不止供应商，开源项目也会迅速的聚集在JSF的四周，争先恐后的去实现相同的功能。比如说，直到我们去实现本质上和Shale的Tapestry差不多的视图的时候，我才知道Facalets。（从长远来看，我相信这种冗余是件好事，会给我们带来好处）
8.POJO Action Methods
Struts的行为是和Struts的API绑定在一起的，但是JSF的行为方法可以在POJPO中实现。这意味着你不用在表单和模型对象之间实现一个多余的行为层。顺便说一下，在JSF里面没有行为对象，行为在模型对象中实现。但是也请注意一点：如果你愿意你也可以生成与JSF独立的行为对象。在Struts里面，你有Form. Bean和Action Bean。Form. Bean包含数据而Action Bean包含逻辑。OO狂会想去合并前2者，在Struts你办不到。但是在JSF中，你可以分开数据和逻辑，也可以合并到一个对象中，一切由你决定。
7.Managed Beans(Dependency Injection 依赖注入)
和Spring一样，JSF也使用了依赖注入（DJ）（或控制反转（IoC））去实例化和初始化Bean。Struts的确为你生成了Form. Bean和Action Bean，但是JSF可以为你生成各种各样的Managed Bean。
6.Extensibility(可扩展性)
这个很重要。JSF有6个对象实现了这个框架的大部分功能，而且你可以很容易的用你自己的实现代替原有实现。比如你想加一个自定义参数在JSF表达式语言里面，或是添加一个自己的视图控制器以便于区分组件和HTML。事实上Shale实现了上面的功能。如果你还没有满足，JSF提供了几个地方你可以轻松的控制JSF的生命周期。Shale给你的会更多。
5.Event Model（事件模型）
JSF的事件模型使你可以对值改变，动作，JSF生命周期阶段变换等作出反应。在JSF1.1中，那些事件都是在服务器端处理的，这肯定是一个缺陷，好在JSF2.0计划支持客户端事件，拭目以待吧。
4.Value Binding Expressions（值绑定表达式）
在Struts中，你负责把数据从Form传递到模型对象。你实现的Action的execute方法是把Form作为一个参数。然后你再手动的把数据从Form. Bean里面取出放到模型对象里面。你要为应用里面的每个Form做这些事情，然而在JSF里面，你只需像这样：#{model.property} 就够了，其他的交给JSF来处理。
3.Renderers
你有看过Struts的标签的源代码吗？它直接生成HTML。JSF组件标签什么都不生成，它和服务器上的一对component-renderer对应。Component维护组件状态，rendered负责获得视图。重点是renderers是可插拔的，即你可以根据自己需求实现然后干洗加盟替代掉默认实现。比如说我在NFJS上面的Felix谈话中举例说明了怎么去实现一个自定义的label renderer。你只需要配置你的renderer，JSF就会自动在你的应用程序里面使用他。
2.Render Kits
在几年前我曾经有份Struts咨询工作，我们必须同时支持浏览器和无线设备，非常痛苦。但是用JSF来完成那个任务非常容易，因为你可以生成你自己的render kit－为一种特定显示技术的renderers的集合－然后配置到JSF里面。
1.Components(组件)
组件是Struts和JSF之间最大的区别。就像Swing一样，JSF提供丰富的底层构件去开发组件然后添加到标准的组件集。那些底层构件让你很容易的生成自己的组件并且和别人共享。现在我们到处都能看到自定义组件跳出来，比如说Oracle的ADF和MyFaces，两者都提供了丰富的组件集，就像javascript日历，tree等等。当然，组件只是一部分。典型的是，组件都和一个独立的renderer对应，这给我们带来了真正的好处（看第3条）。但是和JSF中的很多东西一样，你不一定要墨守成规。只要你愿意，你可以实现render自己的组件，虽然这样你会失去给组件加入别的renderer的能力。
定义线程安全性
明确定义线程安全性出人意料地困难，大多数定义看上去完全是自我循环。快速搜索一下 Google，可以找到以下关于线程安全代码的典型的、但是没有多大帮助的定义(或者可以说是描述)：
...可以从多个编程线程中调用，无需线程之间不必要的交互。
...可以同时被多个线程调用，不需要调用一方有任何操作。
有这样的定义，就不奇怪我们对于线程安全性会感到如此迷惑。这些定义比说“一个类在可以被多个线程安全调用时就是线程安全的”好不了多少，当然，它的意义就是如此，但是它不能帮助我们区分一个线程安全的类与一个线程不安全的类。安全的意义是什么呢?
实际上，所有线程安全的定义都有某种程序的循环，因为它必须符合类的规格说明 -- 这是对类的功能、其副作用、哪些状态是有效和无效的、不可变量、前置条件、后置条件等等的一种非正式的松散描述(由规格说明给出的对象状态约束只应用于外部可见的状态，即那些可以通过调用其公共方法和访问其公共字段看到的状态，而不应用于其私有字段中表示的内部状态)。
线程安全性
类要成为线程安全的，首先必须在单线程环境中有正确的行为。如果一个类实现正确(这是说它符合规格说明的另一种方式)，那么没有一种对这个类的对象的操作序列(读或者写公共字段以及调用公共方法)可以让对象处于无效状态，观察到对象处于无效状态、或者违反类的任何不可变量、前置条件或者后置条件的情况。
此外，一个类要成为线程安全的，在被多个线程访问时，不管运行时环境执行这些线程有什么样的时序安排或者交错，它必须仍然有如上所述的正确行为，并且在调用的代码中没有任何额外的同步。其效果就是，在所有线程看来，对于线程安全对象的操作是以固定的、全局一致的顺序发生的。
正确性与线程安全性之间的关系非常类似于在描述 ACID(原子性、一致性、独立性和持久性)事务时使用的一致性与独立性之间的关系：从特定线程的角度看，由不同线程所执行的对象操作是先后(虽然顺序不定)而不是并行执行的。
方法之问的状态依赖
考虑下面的代码片段，它迭代一个 Vector 中的元素。尽管 Vector 的所有方法都是同步的，但是在多线程的环境中不做额外的同步就使用这段代码仍然是不安全的，因为如果另一个线程恰好在错误的时间里删除了一个元素，则 get() 会抛出一个 ArrayIndexOutOfBoundsException 。
1 Vector v = new Vector();
2 // contains race conditions -- may require external synchronization
3 for (int i=0; i<v.size(); i++) {
4 doSomething(v.get(i));
5 }
6
这里发生的事情是： get(index) 的规格说明里有一条前置条件要求 index 必须是非负的并且小于 size() 。但是，在多线程环境中，没有办法可以知道上一次查到的 size() 值是否仍然有效，因而不能确定 i
更明确地说，这一问题是由 get() 的前置条件是以 size() 的结果来定义的这一事实所带来的。只要看到这种必须使用一种方法的结果作为另一种讲法的输入条件的样式，它就是一个 状态依赖，就必须保证干洗设备至少在调用这两种方法期间元素的状态没有改变。一般来说，做到这一点的唯一方法在调用第一个方法之前是独占性地锁定对象，一直到调用了后一种方法以后。在上面的迭代 Vector 元素的例子中，您需要在迭代过程中同步 Vector 对象。
线程安全程度
如上面的例子所示，线程安全性不是一个非真即假的命题。 Vector 的方法都是同步的，并且 Vector 明确地设计为在多线程环境中工作。但是它的线程安全性是有限制的，即在某些方法之间有状态依赖(类似地，如果在迭代过程中 Vector 被其他线程修改，那么由 Vector.iterator() 返回的 iterator 会抛出 ConcurrentModificationException )。
对于 Java 类中常见的线程安全性级别，没有一种分类系统可被广泛接受，不过重要的是在编写类时尽量记录下它们的线程安全行为。
Bloch 给出了描述五类线程安全性的分类方法：不可变、线程安全、有条件线程安全、线程兼容和线程对立。只要明确地记录下线程安全特性，那么您是否使用这种系统都没关系。这种系统有其局限性 -- 各类之间的界线不是百分之百地明确，而且有些情况它没照顾到 -- 但是这套系统是一个很好的起点。这种分类系统的核心是调用者是否可以或者必须用外部同步包围操作(或者一系列操作)。下面几节分别描述了线程安全性的这五种类别。
不可变
本栏目的普通读者听到我赞美不可变性的优点时不会感到意外。不可变的对象一定是线程安全的，并且永远也不需要额外的同步。因为一个不可变的对象只要构建正确，其外部可见状态永远也不会改变，永远也不会看到它处于不一致的状态。Java 类库中大多数基本数值类如 Integer 、 String 和 BigInteger 都是不可变的。
线程安全
线程安全的对象具有在上面“线程安全”一节中描述的属性 -- 由类的规格说明所规定的约束在对象被多个线程访问时仍然有效，不管运行时环境如何排列，线程都不需要任何额外的同步。这种线程安全性保证是很严格的 -- 许多类，如 Hashtable 或者 Vector 都不能满足这种严格的定义。
有条件的线程安全
我们在 7 月份的文件“ 并发集合类”中讨论了有条件的线程安全。有条件的线程安全类对于单独的操作可以是线程安全的，但是某些操作序列可能需要外部同步。条件线程安全的最常见的例子是遍历由 Hashtable 或者 Vector 或者返回的迭代器 -- 由这些类返回的 fail-fast 迭代器假定在迭代器进行遍历的时候底层集合不会有变化。为了保证其他线程不会在遍历的时候改变集合，进行迭代的线程应该确保它是独占性地访问集合以实现遍历的完整性。通常，独占性的访问是由对锁的干洗同步保证的 -- 并且类的文档应该说明是哪个锁(通常是对象的内部监视器(intrinsic monitor))。
如果对一个有条件线程安全类进行记录，那么您应该不仅要记录它是有条件线程安全的，而且还要记录必须防止哪些操作序列的并发访问。用户可以合理地假设其他操作序列不需要任何额外的同步。
线程兼容
线程兼容类不是线程安全的，但是可以通过正确使用同步而在并发环境中安全地使用。这可能意味着用一个 synchronized 块包围每一个方法调用，或者创建一个包装器对象，其中每一个方法都是同步的(就像 Collections.synchronizedList() 一样)。也可能意味着用 synchronized 块包围某些操作序列。为了最大程度地利用线程兼容类，如果所有调用都使用同一个块，那么就不应该要求调用者对该块同步。这样做会使线程兼容的对象作为变量实例包含在其他线程安全的对象中，从而可以利用其所有者对象的同步。
许多常见的类是线程兼容的，如集合类 ArrayList 和 HashMap 、 java.text.SimpleDateFormat 、或者 JDBC 类 Connection 和 ResultSet 。
线程对立
线程对立类是那些不管是否调用了外部同步都不能在并发使用时安全地呈现的类。线程对立很少见，当类修改静态数据，而静态数据会影响在其他线程中执行的其他类的行为，这时通常会出现线程对立。线程对立类的一个例子是调用 System.setOut() 的类。
其他线程安全记录考虑
线程安全类(以及线程安全性程度更低的的类) 可以允许或者不允许调用者锁定对象以进行独占性访问。 Hashtable 类对所有的同步使用对象的内部监视器，但是 ConcurrentHashMap 类不是这样，事实上没有办法锁定一个 ConcurrentHashMap 对象以进行独占性访问。除了记录线程安全程序，还应该记录是否某些锁 -- 如对象的内部锁 -- 对类的行为有特殊的意义。
通过将类记录为线程安全的(假设它确实 是线程安全的)，您就提供了两种有价值的服务：您告知类的维护者不要进行会影响其线程安全性的修改或者扩展，您还告知类的用户使用它时可以不使用外部同步。通过将类记录为线程兼容或者有条件线程安全的，您就告知了用户这个类可以通过正确使用同步而安全地在多线程中使用。通过将类记录为线程对立的，您就告知用户即使使用了外部同步，他们也不能在多线程中安全地使用这个类。不管是哪种情况，您都在潜在的严重问题出现 之前防止了它们，而要查找和修复这些问题是很昂贵的。
结束语
一个类的线程安全行为是其规格说明中的固有部分，应该成为其文档的一部分。因为(还)没有描述类的线程安全行为的声明式方式，所以必须用文字描述。虽然 Bloch 的描述类的线程安全程度的五层系统没有涵盖所有可能的情况，但是它是一个很好的起点。如果每一个类都将这种线程行为的程度加入到其 Javadoc 中，那么可以肯定的是我们大家都会受益。
我们知道，在操作系统级别上软件的运行一般都是以进程为单位，而在每个进程的运行过程中允许同时并发执行多个不同线程，这就使得一个程序能同时执行不同的操作。使用多线程的目的是为了最大限度地利用计算机CPU资源。JAVA程序字节码最终是在JVM虚拟机下运行的，同一虚拟机进程中的不同操作都是通过多线程来运行的。在JAVA虚拟机中，线程常用有单线程和多线程，单线程指程序执行过程只是一个有效操作的序列，不同操作都有着明确的先后顺序；而多线程允许同时进行着不同的操作，这些不同的操作同时并发进行着，并由CPU时钟频率根据不同的调度方式对他们进行执行调度。
在JAVA语言中提供了丰富的多线程操纵接口，提供了各类不同的线程实现方法供我们选择，功能非常强大。在手机软件设计中，由于同样需要执行网络连接（基于HTTP的高级Internet协议通讯）、UI调度等待、UI显示幻化、游戏控制等操作需要通过后台的上海保洁数据运算或UI不断更新等操作。因此在J2ME中，KVM虚拟机也提供了功能强大的多线程API，使我们同样能在J2ME中实现线程的并发运算。
在J2ME中，主要有以下三种方法实现多线程。
一、继承Thread类（java.lang.Thread）
通过编写线程类继承Thread类并重写Thread类中的run（）方法实现线程，当线程对象被运行时候将会自动执行run方法中的实体内容，从而开辟一个单独的线程并运行起来。
如：public class ThreadSimple extends Thread{
public ThreadSimple()
{
//constructor
}
public void run()
{
//run code entity
}
}
线程实例使用，直接创建对象并调用start（）方法即可运行线程。
new ThreadSimple（）。start（）；当执行start方法时候，将会自动运行run方法，但是执行start方法时候只做了一件事，就是将线程转化为可执行状态，然后等待操作系统进行调度并运行，因此无法保证线程能立即启动。在JAVA中，Thread类实现了Runnable接口，因此run方法是通过实现接口Runnable中的抽象方法。
二、直接实现Runnable多线程接口（java.lang.Runnable）
线程接口Runnable中只有一个抽象方法run，通过实现Runnable接口中的方法的类即可创建出有多线程特征的对象，但该对象并无法使其启动线程，需要作为参数并借助Thread的构造方法构造创建对象并调用start方法对线程进行启动。
如：public class RunnablSimple implements Runnable{
public RunnableSimple()
{
//constructor
}
public void run(){
//run code entity
}
}
实现类型的对象使用：
RunnableSimple rs = new RunnableSimple（）；
new Thread（rs）.start（）；
由此可见，以上两种方法都是通过Thread的start来启动线程的，实际上所有的线程操作都是封装在Thread这个类中，由Thread对象调用各种接口来控制线程。
J2ME中线程中主要方法：void setPriority（int newPriority），设置线程优先级，在操作系统中线程的调度是不确定性的，可以通过该方法设置相应线程的优先级别。
static void sleep（long millis） ，线程中静态方法，用于让线程进入休眠状态，执行该方法将会让线程在指定时间millis毫秒内休眠。
void start（），使现在进入可执行状态。
void run（） ，线程执行主体。
void join（），等待该线程终止。
boolean isAlive（），用于判断线程是否出于Alive状态。
static void yield（） ，尽量让其他线程先执行。
三、使用任务组合实现多线程
在J2ME中，同样具有JAVA中的任务处理组合类，他们分别为Timer和TimerTask，可以使用他们实现多线程，简单说就是定时实现任务。
Timer是JAVA中的一个定时器，可以实现在某一时间做某件事或者在某一时间段做某些事，分别通过方法schedule（TimerTask tt，long millis）和schedule（TimerTask tt，long start，long off）。
TimerTask是一个任务类，通过继承该类并覆盖方法run即可创建一个任务。
如：public class TimerTaskS extends TimerTask{
public TimerTaskS(){
//constructor
}
public void run(){
//run code entity
}
}
任务调用：
Timer timer = new Timer（）；
//3秒钟后执行任务
timer.schedule（new TimerTaskS（），3000）；
//3秒钟后执行任务并且之后每5秒钟执行一次
timer.schedule（new TimerTaskS（），3000，5000）；
有此可见在使用计时任务可以达到实现线程的效果，分别执行不同的并发操作，通过Timer类对象来操作TimerTask对象，通过schedule方法来计时执行任务，在结束任务的时候，通常使用cancel（）来实现。
通常情况下，在J2ME软件中我们通过手机按键来触发一系列相应的操作，在程序响应处理过程中较多会涉及网络操作、数据存储等相对消耗时间和资源的操作，而这些操作往往需要一定的时间才能完成，因此在处理按键响应过程中通常我们需要建立干洗设备线程处理，避免程序出现死机现象。
public void commandAction(Command c, Displayable s) {
if(c==do1Com){
//创建实现接口线程
new Thread(new RunnableSimple()).start()；
}
else if(c==do2Com){
//创建继承Thread线程
new ThreadSimple().start();
}
else{
//创建任务线程
new Timer().schedule(new TimerTaskS(),3000,20);
}
}
描述：
计数代理模式在客户对象调用服务提供者对象上方法的前后执行诸如日志（logging）和计数（counting）一系列附加功能时很有用。计数代理模式建议把这些附加功能封装在一个单独的对象，这个对象就是指计数代理对象，而不是把这些附加的功能实现放到服务提供者的内部。良好的对象设计的一个特征就是对象要专注于提供特定的功能。换句话说，理想的对象不应该做各种不相干高周波的事情。把诸如日志（logging）和计数（counting）等类似的功能封装为一个单独的对象，而让服务提供者对象仅提供它自己的特定功能。也就是说，只允许服务提供者对象执行定义良好、特定的任务。
计数代理被设计成可以被客户访问的与服务提供者具有相同接口的对象。客户对象不是直接访问服务提供者，而是调用计数代理对象上的方法，计数代理执行必要的纪录日志（logging）和计数（counting）功能后，再把方法调用传递给服务提供着对象。如图1
Figure1: Generic Class Association When the Counting Proxy Pattern Is Applied
下面的例子说明了如何在应用程序中利用计数代理。
例子：
让我们设计一个Order类，类层次如图2，OrderIF接口声明了getAllOrders读取数据库中所有订单的简单方法。
Figure2: Order Class Hierarchy
public interface OrderIF {
public Vector getAllOrders();
}
作为getAllOrders方法实现的一部分，Order类实用了FileUtil工具类从order.txt文件中读取订单项。
public class Order implements OrderIF {
public Vector getAllOrders() {
FileUtil fileUtil = new FileUtil();
Vector v = fileUtil.fileToVector("orders.txt");
return v;
}
}
让我们假定在调用getAllOrders()时，需要把取数据文件所花费的时间和记录条数要吸亲自出吸塑机记录的log日志文件中。
这个附加的功能可以设计一个单独的OrderProxy类来实现，它与真实对象Order一样实现OrderIF接口。这样保证了OrderProxy对象提供给客户与真实对象Order一样的接口。如图3
Figure3: Order Class Hierarchy with the Counting Proxy
public class OrderProxy implements OrderIF {
private int counter = 0;
public Vector getAllOrders() {
Order order = new Order();
counter++;
long t1 = System.currentTimeMillis ();
Vector v = order.getAllOrders();
long t2 = System.currentTimeMillis();
long timeDiff = t2 ? t1;
String msg = "Iteration=" + counter + "::Time=" + timeDiff + "ms";
//log the message
FileUtil fileUtil = new FileUtil();
fileUtil.writeToFile("log.txt”,msg, true, true);
return v;
}
}
客户对象MainApp就想调用真实对象Order一样调用OrderProxy对象上的getAllOrders()方法，OrderProxy对象传递这个调用给真实对象Order,计算读取所有订单所花费的时间并使用FileUtil帮助类将其纪录的log日志文件中。在这个过程中，OrderProxy扮演者计数代理的角色。
public class MainApp {
public static void main(String[] args) {
OrderIF order = new OrderProxy();
Vector v = order.getAllOrders();
v = order.getAllOrders();
v = order.getAllOrders();
v = order.getAllOrders();
}
}
在 Java 程序中使用多线程要比在 C 或 C++ 中容易得多，这是因为 Java 编程语言提供了语言级的支持。本文通过简单的编程示例来说明 Java 程序中的多线程是多么直观。读完本文以后，用户应该能够编写简单的多线程程序。
为什么会排队等待?
下面的这个简单的 Java 程序完成四项不相关的任务。这样的程序有单个控制线程，控制在这四个任务之间线性地移动。此外，因为所需的资源 ? 打印机、磁盘、数据库和显示屏 -- 由于硬件和软件的限制都有内在的潜伏时间，所以每项任务都包含明显的等待时间。因此，程序在访问数据库之前必须等待打印机完成打印文件的任务，等等。如果您正在等待程序的完成，则这是对计算资源和您的时间的一种拙劣使用。改进此程序的一种方法是使它成为多线程的。
四项不相关的任务
class myclass {
static public void main(String args[]) {
print_a_file();
manipulate_another_file();
access_database();
draw_picture_on_screen();
}
}
在本例中，每项任务在开始之前必须等待前一项任务完成，即使所涉及的任务毫不相关也是这样。但是，在现实生活中，我们经常使用多线程模型。我们在处理某些任务的同时也可以让孩子、配偶和父母完成别的任务。例如，我在写信的同时可能打发我的儿子去邮局买邮票。用软件术语来说，这称为多个控制(或执行)线程。
可以用两种不同的方法来获得多个控制线程：
多个进程
在大多数操作系统中都可以创建多个进程。当一个程序启动时，它可以为即将开始的每项任务创建一个进程，并允许它们同时运行。当一个程序因等待网络访问或用户输入而被阻塞时，另一个程序还可以运行，这样就增加了干洗设备资源利用率。但是，按照这种方式创建每个进程要付出一定的代价：设置一个进程要占用相当一部分处理器时间和内存资源。而且，大多数操作系统不允许进程访问其他进程的内存空间。因此，进程间的通信很不方便，并且也不会将它自己提供给容易的编程模型。
线程
线程也称为轻型进程 (LWP)。因为线程只能在单个进程的作用域内活动，所以创建线程比创建进程要廉价得多。这样，因为线程允许协作和数据交换，并且在计算资源方面非常廉价，所以线程比进程更可取。线程需要操作系统的支持，因此不是所有的机器都提供线程。Java 编程语言，作为相当新的一种语言，已将线程支持与语言本身合为一体，这样就对线程提供了强健的支持。
使用 Java 编程语言实现线程
Java编程语言使多线程如此简单有效，以致于某些程序员说它实际上是自然的。尽管在 Java 中使用线程比在其他语言中要容易得多，仍然有一些概念需要掌握。要记住的一件重要的事情是 main() 函数也是一个线程，并可用来做有用的工作。程序员只有在需要多个线程时才需要创建新的线程。
Thread 类
Thread 类是一个具体的类，即不是抽象类，该类封装了线程的行为。要创建一个线程，程序员必须创建一个从 Thread 类导出的新类。程序员必须覆盖 Thread 的 run() 函数来完成有用的工作。用户并不直接调用此函数;而是必须调用 Thread 的 start() 函数，该函数再调用 run()。下面的代码说明了它的用法：
创建两个新线程
import java.util.*;
class TimePrinter extends Thread {
int pauseTime;
String name;
public TimePrinter(int x, String n) {
pauseTime = x;
name = n;
}
public void run() {
while(true) {
try {
System.out.println(name + ":" + new
Date(System.currentTimeMillis()));
Thread.sleep(pauseTime);
} catch(Exception e) {
System.out.println(e);
}
}
}
static public void main(String args[]) {
TimePrinter tp1 = new TimePrinter(1000, "Fast Guy");
tp1.start();
TimePrinter tp2 = new TimePrinter(3000, "Slow Guy");
tp2.start();
}
}
在本例中，我们可以看到一个简单的程序，它按两个不同的时间间隔(1 秒和 3 秒)在屏幕上显示当前时间。这是通过创建两个新线程来完成的，包括 main() 共三个线程。但是，因为有时要作为线程运行的类可能已经是某个类层次的一部分，所以就不能再按这种机制创建干洗机线程。虽然在同一个类中可以实现任意数量的接口，但 Java 编程语言只允许一个类有一个父类。同时，某些程序员避免从 Thread 类导出，因为它强加了类层次。对于这种情况，就要 runnable 接口。
Runnable 接口
此接口只有一个函数，run()，此函数必须由实现了此接口的类实现。但是，就运行这个类而论，其语义与前一个示例稍有不同。我们可以用 runnable 接口改写前一个示例。(不同的部分用黑体表示。)
创建两个新线程而不强加类层次
import java.util.*;
class TimePrinter implements Runnable {
int pauseTime;
String name;
public TimePrinter(int x, String n) {
pauseTime = x;
name = n;
}
public void run() {
while(true) {
try {
System.out.println(name + ":" + new
Date(System.currentTimeMillis()));
Thread.sleep(pauseTime);
} catch(Exception e) {
System.out.println(e);
}
}
}
static public void main(String args[]) {
Thread t1 = new Thread(new TimePrinter(1000, "Fast Guy"));
t1.start();
Thread t2 = new Thread(new TimePrinter(3000, "Slow Guy"));
t2.start();
}
}
请注意，当使用 runnable 接口时，您不能直接创建所需类的对象并运行它;必须从 Thread 类的一个实例内部运行它。许多程序员更喜欢 runnable 接口，因为从 Thread 类继承会强加类层次。
synchronized 关键字
到目前为止，我们看到的示例都只是以非常简单的方式来利用线程。只有最小的数据流，而且不会出现两个线程访问同一个对象的情况。但是，在大多数有用的程序中，线程之间通常有信息流。试考虑一个金融应用程序，它有一个 Account 对象，如下例中所示：
一个银行中的多项活动
public class Account {
String holderName;
float amount;
public Account(String name, float amt) {
holderName = name;
amount = amt;
}
public void deposit(float amt) {
amount += amt;
}
public void withdraw(float amt) {
amount -= amt;
}
public float checkBalance() {
return amount;
}
}
在此代码样例中潜伏着一个错误。如果此类用于单线程应用程序，不会有任何问题。但是，在多线程应用程序的情况中，不同的线程就有可能同时访问同一个 Account 对象，比如说一个联合帐户的所有者在不同的 ATM 上同时进行访问。在这种情况下，存入和支出就可能以这样的方式发生：一个事务被另一个事务覆盖。这种情况将是灾难性的。但是，Java 编程语言提供了一种简单的机制来防止发生这种覆盖。每个对象在运行时都有一个关联的锁。这个锁可通过为方法添加关键字 synchronized 来获得。这样，修订过的 Account 对象(如下所示)将不会遭受像数据损坏这样的错误：
对一个银行中的多项活动进行同步处理
public class Account {
String holderName;
float amount;
public Account(String name, float amt) {
holderName = name;
amount = amt;
}
public synchronized void deposit(float amt) {
amount += amt;
}
public synchronized void withdraw(float amt) {
amount -= amt;
}
public float checkBalance() {
return amount;
}
}
deposit() 和 withdraw() 函数都需要这个锁来进行操作，所以当一个函数运行时，另一个函数就被阻塞。请注意， checkBalance() 未作更改，它严格是一个读函数。因为 checkBalance() 未作同步处理，所以任何其他方法都不会阻塞它，它也不会阻塞任何其他方法，不管那些方法是否进行了同步处理。
Java 编程语言中的高级多线程支持
线程组
线程是被个别创建的，但可以将它们归类到线程组中，以便于调试和监视。只能在创建线程的同时将它与一个线程组相关联。在使用大量线程的程序中，使用线程组组织线程可能很有帮助。可以将它们看作是计算机上的目录和文件结构。
线程间发信
当线程在继续执行前需要等待一个条件时，仅有 synchronized 关键字是不够的。虽然 synchronized 关键字阻止并发更新一个对象，但它没有实现线程间发信。Object 类为此提供了三个函数：wait()、notify() 和 notifyAll()。以全球气候预测程序为例。这些程序通过将地球分为许多单元，在每个循环中，每个单元的计算都是隔离进行的，直到这些值趋于稳定，然后相邻单元之间就会交换一些数据。所以，从本质上讲，在每个循环中各个线程都必须等待所有线程完成各自的任务以后才能进入下一个循环。这个模型称为 屏蔽同步，下例说明了这个模型：
屏蔽同步
public class BSync {
int totalThreads;
int currentThreads;
public BSync(int x) {
totalThreads = x;
currentThreads = 0;
}
public synchronized void waitForAll() {
currentThreads++;
if(currentThreads < totalThreads) {
try {
wait();
} catch (Exception e) {}
}
else {
currentThreads = 0;
notifyAll();
}
}
}
当对一个线程调用 wait() 时，该线程就被有效阻塞，只到另一个线程对同一个对象调用 notify() 或 notifyAll() 为止。因此，在前一个示例中，不同的线程在完成它们的工作以后将调用 waitForAll() 函数，最后一个线程将触发 notifyAll() 函数，该函数将释放所有的线程。第三个函数 notify() 只通知一个正在等待的线程，当对每次只能由一个线程使用的资源进行访问限制时，这个函数很有用。但是，不可能预知哪个线程会获得这个通知，因为这取决于 Java 虚拟机 (JVM) 调度算法。
将 CPU 让给另一个线程
当线程放弃某个稀有的资源(如数据库连接或网络端口)时，它可能调用 yield() 函数临时降低自己的优先级，以便某个其他线程能够运行。
守护线程
有两类线程：用户线程和守护线程。用户线程是那些完成有用工作的线程。 守护线程是那些仅提供辅助功能的线程。Thread 类提供了 setDaemon() 函数。Java 程序将运行到所有用户线程终止，然后它将破坏所有的守护线程。在 Java 虚拟机 (JVM) 中，即使在 main 结束以后，如果另一个用户线程仍在运行，则程序仍然可以继续运行。
避免不提倡使用的方法
不提倡使用的方法是为支持向后兼容性而保留的那些方法，它们在以后的版本中可能出现，也可能不出现。Java 多线程支持在版本 1.1 和版本 1.2 中做了重大修订，stop()、suspend() 和 resume() 函数已不提倡使用。这些函数在 JVM 中可能引入微妙的错误。虽然函数名可能听起来很诱人，但请抵制诱惑不要使用它们。
调试线程化的程序
在线程化的程序中，可能发生的某些常见而讨厌的情况是死锁、活锁、内存损坏和资源耗尽。
死锁
死锁可能是多线程程序最常见的问题。当一个线程需要一个资源而另一个线程持有该资源的锁时，就会发生死锁。这种情况通常很难检测。但是，解决方案却相当好：在所有的线程中按相同的次序获取所有资源锁。例如，如果有四个资源 ?A、B、C 和 D ? 并且一个线程可能要获取四个资源中任何一个资源的锁，则请确保在获取对 B 的锁之前首先获取对 A 的锁，依此类推。如果“线程 1”希望获取对 B 和 C 的锁，而“线程 2”获取了 A、C 和 D 的锁，则这一技术可能导致阻塞，但它永远不会在这四个锁上造成死锁。
活锁
当一个线程忙于接受新任务以致它永远没有机会完成任何任务时，就会发生活锁。这个线程最终将超出缓冲区并导致程序崩溃。试想一个秘书需要录入一封信，但她一直在忙于接电话，所以这封信永远不会被录入。
内存损坏
如果明智地使用 synchronized 关键字，则完全可以避免内存错误这种气死人的问题。
资源耗尽
某些系统资源是有限的，如文件描述符。多线程程序可能耗尽资源，因为每个线程都可能希望有一个这样的资源。如果线程数相当大，或者某个资源的侯选线程数远远超过了可用的资源数，则最好使用 资源池。一个最好的示例是数据库连接池。只要线程需要使用一个数据库连接，它就从池中取出一个，使用以后再将它返回池中。资源池也称为 资源库。
调试大量的线程
有时一个程序因为有大量的线程在运行而极难调试。在这种情况下，下面的这个类可能会派上用场：
public class Probe extends Thread {
public Probe() {}
public void run() {
while(true) {
Thread[] x = new Thread[100];
Thread.enumerate(x);
for(int i=0; i<100; i++) {
Thread t = x[i];
if(t == null)
break;
else
System.out.println(t.getName() + "\t" + t.getPriority()
+ "\t" + t.isAlive() + "\t" + t.isDaemon());
}
}
}
}
限制线程优先级和调度
Java 线程模型涉及可以动态更改的线程优先级。本质上，线程的优先级是从 1 到 10 之间的一个数字，数字越大表明任务越紧急。JVM 标准首先调用优先级较高的线程，然后才调用优先级较低的线程。但是，该标准对具有相同优先级的线程的处理是随机的。如何处理这些线程取决于基层的操作系统策略。在某些情况下，优先级相同的线程分时运行;在另一些情况下，线程将一直运行到结束。请记住，Java 支持 10 个优先级，基层操作系统支持的优先级可能要少得多，这样会造成一些混乱。因此，只能将优先级作为一种很粗略的工具使用。最后的控制可以通过明智地使用 yield() 函数来完成。通常情况下，请不要依靠线程优先级来控制线程的状态。
小结
本文说明了在 Java 程序中如何使用线程。像是否应该使用线程这样的更重要的问题在很大程序上取决于手头的应用程序。决定是否在应用程序中使用多线程的一种方法是，估计可以并行运行的代码量。并记住以下几点：
使用多线程不会增加 CPU 的能力。但是如果使用 JVM 的本地线程实现，则不同的线程可以在不同的处理器上同时运行(在多 CPU 的机器中)，从而使多 CPU 机器得到充分利用。
如果应用程序是计算密集型的，并受 CPU 功能的制约，则只有多 CPU 机器能够从更多的线程中受益。
当应用程序必须等待缓慢的资源(如网络连接或数据库连接)时，或者当应用程序是非交互式的时，多线程通常是有利的。
基于 Internet 的软件有必要是多线程的;否则，用户将感觉应用程序反映迟钝。例如，当开发要支持大量客户机的服务器时，多线程可以使编程较为容易。在这种情况下，每个线程可以为不同的客户或客户组服务，从而缩短了响应时间。
某些程序员可能在 C 和其他语言中使用过线程，在那些语言中对线程没有语言支持。这些程序员可能通常都被搞得对线程失去了信心。
import java.security.Key;
import java.security.KeyFactory;
import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.interfaces.RSAPrivateKey;
import java.security.interfaces.RSAPublicKey;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;
import javax.crypto.Cipher;
import sun.misc.BASE64Decoder;
import sun.misc.BASE64Encoder;
public class RSACoder {
/**
* 得到公钥
* @param key 密钥字符串（经过base64编码）
* @throws Exception
*/
public static PublicKey getPublicKey(String key) throws Exception {
byte[] keyBytes;
keyBytes = (new BASE64Decoder()).decodeBuffer(key);
X509EncodedKeySpec keySpec = new X509EncodedKeySpec(keyBytes);
KeyFactory keyFactory = KeyFactory.getInstance("RSA");
PublicKey publicKey = keyFactory.generatePublic(keySpec);
return publicKey;
}
/**
* 得到私钥
* @param key 密钥字符串（经过base64编码）
* @throws Exception
*/
public static PrivateKey getPrivateKey(String key) throws Exception {
byte[] keyBytes;
keyBytes = (new BASE64Decoder()).decodeBuffer(key);
PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(keyBytes);
KeyFactory keyFactory = KeyFactory.getInstance("RSA");
PrivateKey privateKey = keyFactory.generatePrivate(keySpec);
return privateKey;
}
/**
* 得到密钥字符串（经过base64编码）
* @return
*/
public static String getKeyString(Key key) throws Exception {
byte[] keyBytes = key.getEncoded();
String s = (new BASE64Encoder()).encode(keyBytes);
return s;
}
public static void main(String[] args) throws Exception {
KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA");
//密钥位数
keyPairGen.initialize(1024);
//密钥对
KeyPair keyPair = keyPairGen.generateKeyPair();
// 公钥
PublicKey publicKey = (RSAPublicKey) keyPair.getPublic();
// 私钥
PrivateKey privateKey = (RSAPrivateKey) keyPair.getPrivate();
String publicKeyString = getKeyString(publicKey);
System.out.println("public:\n" + publicKeyString);
String privateKeyString = getKeyString(privateKey);
System.out.println("private:\n" + privateKeyString);
//加解密类
Cipher cipher = Cipher.getInstance("RSA");//Cipher.getInstance("RSA/ECB/PKCS1Padding");
//明文
byte[] plainText = "我们都很好！邮件：@sina.com".getBytes();
//加密
cipher.init(Cipher.ENCRYPT_MODE, publicKey);
byte[] enBytes = cipher.doFinal(plainText);
//通过密钥字符串得到密钥
publicKey = getPublicKey(publicKeyString);
privateKey = getPrivateKey(privateKeyString);
//解密
cipher.init(Cipher.DECRYPT_MODE, privateKey);
byte[]deBytes = cipher.doFinal(enBytes);
publicKeyString = getKeyString(publicKey);
System.out.println("public:\n" +publicKeyString);
privateKeyString = getKeyString(privateKey);
System.out.println("private:\n" + privateKeyString);
String s = new String(deBytes);
System.out.println(s);
}
}
最近在开发Java的程序。本来我是一直很喜欢Java的内存管理的，不需要担心分配内存，只管分配，垃圾收集器自己会给你回收内存的。现在开发的程序数据量很大，为了速度快，我准备把所有的信息加载进内存，这样可以保证快速响应。我还在反复算内存，想想自己的数据量，现在刚开始的时候应该够了（我的机器是4G内存，虽然Windows就认3.5G，但是比起我现在的数据量应该没问题）。
没想到第一个实验的程序，跑了几个小时，就遇到了Out of Memory Exception了。看看自己的虚拟机设置，我设置的是-Xms512M -Xmx1024M。想都没想，直接改成-Xms512M -Xmx2048M，结果直接就Could not reserve enough space for object heap。程序都起不来了。这才发现原来最大内存还有限制。上网搜了一下干洗机，发现很多讨论这个问题的文章。最终在BEA的DEV2DEV论坛发现了最有用的一篇http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=121&threadID= 35704&start=0&tstart=0
这里的版主YuLimin 做了测试，得出结论：
公司 JVM版本 最大内存(兆)client 最大内存(兆)server
SUN 1.5.x 1492 1520
SUN 1.5.5(Linux) 2634 2660
SUN 1.4.2 1564 1564
SUN 1.4.2(Linux) 1900 1260
IBM 1.4.2(Linux) 2047 N/A
BEA JRockit 1.5 (U3) 1909 1902
我现在用的是JDK1.6. 0_05，测试了一下。在Client状态下最大是，我的JDK不认-Server参数，测试不了Server状态。估计差不多。
SUN 1.6.0 1442 N/a
看样子用Java想用大内存也是不可能的了。而且一般的说法是内存太大了，垃圾收集的时间就会长。这也可以理解，一般是内存不够用了才收集的，扫描2G内存比1G当然要慢多了，而且内存对象多了，估计关系是指数上升的。
下面附上YuLimin的测试方法和测试记录。
测试方法：在命令行下用 java -XmxXXXXM -version 命令来进行测试，然后逐渐的增大XXXX的值，如果执行正常就表示指定的内存大小可用，否则会打印错误信息。
测试记录：
我在Windows 2000 ADS上面测试内存使用的结果如下
SUN的1.2.2、1.3.1、1.4.2、1.5.0、IBM1.4.2、BEA JRockit 1.4.2
F:\JDK\1.2.2\bin>java -Xmx700000255M -version
java version “1.2.2″
Classic VM (build JDK-1.2.2_017, native threads, symcjit)
F:\JDK\1.2.2\bin>java -Xmx700000256M -version
Bad max heap size: -Xmx700000256M
Could not create the Java virtual machine.
=====================================================================
F:\JDK\1.3.1\bin>java -version
java version “1.3.1_18″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_18-b01)
Java HotSpot(TM) Client VM (build 1.3.1_18-b01, mixed mode)
F:\JDK\1.3.1\bin>REM If present, the option to select the VM must be first.
F:\JDK\1.3.1\bin>REM The default VM is -hotspot.
F:\JDK\1.3.1\bin>java -hotspot -Xmx1554M -version
java version “1.3.1_18″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_18-b01)
Java HotSpot(TM) Client VM (build 1.3.1_18-b01, mixed mode)
F:\JDK\1.3.1\bin>java -hotspot -Xmx1555M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
F:\JDK\1.3.1\bin>java -server -Xmx1522M -version
java version “1.3.1_18″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_18-b01)
Java HotSpot(TM) Server VM (build 1.3.1_18-b01, mixed mode)
F:\JDK\1.3.1\bin>java -server -Xmx1523M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
F:\JDK\1.3.1\bin>java -classic -Xmx2047M -version
java version “1.3.1_18″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_18-b01)
Classic VM (build 1.3.1_18-b01, native threads, nojit)
F:\JDK\1.3.1\bin>java -classic -Xmx2048M -version
Bad max heap size: -Xmx2048M
Could not create the Java virtual machine.
=====================================================================
F:\JDK\1.4.2\bin>java -version
java version “1.4.2_12″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03)
Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode)
F:\JDK\1.4.2\bin>REM The default VM is client.
F:\JDK\1.4.2\bin>java -client -Xmx1308M -version
java version “1.4.2_12″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03)
Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode)
F:\JDK\1.4.2\bin>java -client -Xmx1309M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
F:\JDK\1.4.2\bin>java -server -Xmx1308M -version
java version “1.4.2_12″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03)
Java HotSpot(TM) Server VM (build 1.4.2_12-b03, mixed mode)
F:\JDK\1.4.2\bin>java -server -Xmx1309M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
F:\JDK\1.4.2\bin>REM -hotspot is a synonym for the “client” VM [deprecated]
F:\JDK\1.4.2\bin>java -hotspot -Xmx1308M -version
java version “1.4.2_12″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03)
Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode)
F:\JDK\1.4.2\bin>java -hotspot -Xmx1309M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
F:\JDK\1.5.0\bin>java -version
java version “1.5.0_07″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)
F:\JDK\1.5.0\bin>java -client -Xmx1492M -version
java version “1.5.0_07″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode)
F:\JDK\1.5.0\bin>java -client -Xmx1493M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
F:\JDK\1.5.0\bin>java -server -Xmx1504M -version
java version “1.5.0_07″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode)
F:\JDK\1.5.0\bin>java -server -Xmx1505M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
F:\JDK\1.5.0\bin>REM -hotspot is a synonym for the “client” VM [deprecated]
F:\JDK\1.5.0\bin>java -hotspot -Xmx1492M -version
java version “1.5.0_07″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode)
F:\JDK\1.5.0\bin>java -hotspot -Xmx1493M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
=====================================================================
F:\JDK\IBM142\bin>java -version
java version “1.4.2″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn1420-20040626 (JIT enabled: jitc))
F:\JDK\IBM142\bin>REM The default VM is client.
F:\JDK\IBM142\bin>java -Xmx2047M -version
java version “1.4.2″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn1420-20040626 (JIT enabled: jitc))
F:\JDK\IBM142\bin>java -Xmx2048M -version
[ Unable to allocate an initial java heap of 2147483648 bytes. ]
[ **Out of memory, aborting** ]
[ ]
[ *** panic: JVMST016: Cannot allocate memory for initial java heap ]
abnormal program termination
F:\BEA\JRockit\bin>java -version
java version “1.4.2_05″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-win-ia32, Native Threads, GC strategy: parallel)
F:\BEA\JRockit\bin>REM The default VM is jrockit.
F:\BEA\JRockit\bin>java -Xmx1617M -version
java version “1.4.2_05″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-win-ia32, Native Threads, GC strategy: parallel)
F:\BEA\JRockit\bin>java -Xmx1618M -version
Unable to acquire some virtual address space - reduced from 1656832 to 1640260 KB!
java version “1.4.2_05″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-win-ia32, Native Threads, GC strategy: parallel)
F:\BEA\JRockit\bin>REM -jrockit to select the “jrockit” VM
F:\BEA\JRockit\bin>java -jrockit -Xmx1617M -version
java version “1.4.2_05″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-win-ia32, Native Threads, GC strategy: parallel)
F:\BEA\JRockit\bin>java -jrockit -Xmx1618M -version
Unable to acquire some virtual address space - reduced from 1656832 to 1640260 KB!
java version “1.4.2_05″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
BEA WebLogic JRockit(TM) 1.4.2_05 JVM R24.4.0-1 (build ari-38120-20041118-1131-win-ia32, Native Threads, GC strategy: parallel)
我的测试记录：
C:\>java -client -Xmx1441M -version
java version “1.6.0_05″
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode)
C:\>java -client -Xmx1442M -version
java version “1.6.0_05″
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode)
C:\>java -client -Xmx1443M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
C:\>java -server -Xmx1443M -version
Error: no `server’ JVM at `C:\Program Files\Java\jre1.6.0_05\bin\server\jvm.dll’
基本数据的类型的大小是固定的，这里就不多说了。对于非基本类型的Java对象，其大小就值得商榷。
在Java中，一个空Object对象的大小是8byte，这个大小只是保存堆中一个没有任何属性的对象的大小。看下面语句：
Object ob = new Object();
这样在程序中完成了一个Java对象的生命，但是它所占的空间为：4byte+8byte。4byte是上面部分所说的Java栈中保存引用的所需要的空间。而那8byte则是Java堆中对象的信息。因为所有的Java非基本类型的对象都需要默认继承Object对象，因此不论什么样的Java对象，其大小都必须是大于8byte。
有了Object对象的大小，我们就可以计算其他对象的大小了。
Class NewObject { int count; boolean flag; Object ob; }
其大小为：空对象大小(8byte)+int大小(4byte)+Boolean大小(1byte)+空Object引用的大小(4byte)=17byte。但是因为Java在对对象内存分配时都是以8的整数倍来分，因此大于17byte的最接近8的整数倍的是24，因此此对象的大小为24byte。
这里需要注意一下基本类型的包装类型的大小。因为这种包装类型已经成为对象了，因此需要把他们作为对象来看待。包装类型的大小至少是12byte(声明一个空Object至少需要的空间)，而且12byte没有包含任何有效卫星电视信息，同时，因为Java对象大小是8的整数倍，因此一个基本类型包装类的大小至少是16byte。这个内存占用是很恐怖的，它是使用基本类型的N倍(N>2)，有些类型的内存占用更是夸张(随便想下就知道了)。因此，可能的话应尽量少使用包装类。在JDK5.0以后，因为加入了自动类型装换，因此，Java虚拟机会在存储方面进行相应的优化。
引用类型
对象引用类型分为强引用、软引用、弱引用和虚引用。
强引用:就是我们一般声明对象是时虚拟机生成的引用，强引用环境下，垃圾回收时需要严格判断当前对象是否被强引用，如果被强引用，则不会被垃圾回收
软引用:软引用一般被做为缓存来使用。与强引用的区别是，软引用在垃圾回收时，虚拟机会根据当前系统的剩余内存来决定是否对软引用进行回收。如果剩余内存比较紧张，则虚拟机会回收软引用所引用的空间;如果剩余内存相对富裕，则不会进行回收。换句话说，虚拟机在发生OutOfMemory时，肯定是没有软引用存在的。
弱引用:弱引用与软引用类似，都是作为缓存来使用。但与软引用不同，弱引用在进行垃圾回收时，是一定会被回收掉的，因此其生命周期只存在于一个垃圾回收周期内。
强引用不用说，我们系统一般在使用时都是用的强引用。而“软引用”和“弱引用”比较少见。他们一般被作为缓存使用，而且一般是在内存大小比较受限的情况下做为缓存。因为如果内存足够大的话，可以直接使用强引用作为缓存即可，同时可控性更高。因而，他们常见的是被使用在桌面应用系统的缓存。
所有的Hibernate应用中都会访问Hibernate的5个核心接口。
Configuration接口：配置Hibernate,根启动Hibernate，创建SessionFactory对象。
SessionFactory接口：初始化Hibernate，充当数据存储源的代理，创建Session对象。
Session接口：负责保存、更新、删除、加载和查询对象。
Transaction：管理事务。
Query和Criteria接口：执行数据库查询。
1.Configuration接口
Configuration对象用于配置并且启动Hibernate。Hibernate应用通过Configuration实例来指定对象-关系映射文件的位置或者动态配置Hibernate的属性，然后创建SessionFactory实例。
2.SessionFactory接口
一个SessionFactory实例对应一个数据存储源，应用从SessionFactory中获得Session实例。SessionFactory有以下特点：
它是线程安全的，这意味着它的同一个实例可以被应用的多个线程共享。
它是重量级的，这意味着不能随意创建或销毁它的实例。如果应用只访问一个数据库，只需要创建一个SessionFactory实例，在应用初始化的时候创建该实例。如果应用同时访问多个数据库，则需要为每个干洗机创建数据库创建一个单独的SessionFactory实例。
之所以称SessionFactory是重量级的，是因为它需要一个很大的缓存，用来存放预定义的SQL语句以能映射元数据等。用户还可以为SesionFactory配置一个缓存插件，这个缓存插件被称为Hibernate的第二级缓存。，该缓存用来存放被工作单元读过的数据，将来其他工作单元可能会重用这些数据，因此这个缓存中的数据能够被所有工作单元共享。一个工作单元通常对应一个数据库事务。
3.Session接口
Session接口是Hibernate应用使用最广泛的接口。Session也被称为持久化管理器，它提供了和持久化相关的操作，如添加、更新、删除、加载和查询对象。
Session有以下特点：
不是线程安全的，因此在设计软件架构时，应该避免多个线程共享同一个Session实例。
Session实例是轻量级的，所谓轻量级，是指它的创建和销毁不需要消耗太多的资源。这意味着在程序中可以经常创建和销毁Session对象，例如为每个客户请示分配单独的Session实例，或者为每个工作单元分配单独的Session实例。
Session有一个缓存，被称为Hibernate的第一级缓存，它存放被当前工作单元加载的对象。每个Session实例都有自己的缓存，这个Sesion实例的缓存只能被当前工作单元访问。
4.Transaction接口
Transaction接口是Hibernate的数据库事务接口，它对底层的事务接口做了封装，底层事务接口包括：
JDBC API、JTA(Java Transaction API)、CORBA(Common Object Requet Broker Architecture)API
Hibernate应用可通过一致的Transaction接口来声明事务边界，这有助于应用在不同的环境容器中移植。尽管应用也可以绕过Transaction接口，直接访问底层的事务接口，这种方法不值得推荐，因为它不利于应用在不同的环境移植。
5.Query和Criteria接口
Query和Criteria接口是Hibernate的查询接口，用于向数据库查询对象，以及控制执行查询的过程。Query实例包装了一个HQL查询语句，HQL查询语句和SQL查询语句有些相似，但HQL查询语句是面向对象的，它引用类句及类的属性句，而不是表句及表的字段句。Criteria接口完全封装了基于字符串的查询语句，比Query接口更加面向对象，Criteria接口擅长执行动态查询。
Session接口的find()方法也具有数据查询功能，但它只是执行一些简单的HQL查询语句的快捷方法，它的功能远没有Query接口强大。