Java项目设计与开发范例

JavaWeb应用开发框架实例

一、 概述

Web 应用架构可以划分为两大子系统：前端子系统和后台子系统。

前端子系统：

1. 基础技术： Html/Java/CSS / Flash

2. 开发框架： jQuery, Extjs , Flex 等;

后台子系统：

1. 基础技术： Java Servlet;

2. 开发框架： Struts, Spring, Hibernate, ibatis 等;

3. 应用服务器： Tomcat / Jetty

编程模型： B/S 模型。 客户端向服务器端发送请求， 服务器经过处理后返回响应， 然后客户端根据响应及需求绘制前端展现。

在用户客户端和实际提供功能的Web 服务器之间还可能存在着代理服务器， 负载均衡服务器， 不过那些属于锦上添花的事物，暂时不在考虑范围内。

客户端应用理念： 客户端承担大量的交互逻辑及渲染工作，服务器端主要是处理请求和返回数据。

前后端系统耦合： 客户端和服务器端各自处理自己内部的子系统耦合;而客户端与服务器端的耦合简化为一个通信与数据通道。该通道用来传输通信请求和返回数据。

请求通信： 采用 Http / Tcp 协议

数据通道： 采用 Json, xml , 文本字符串，字节。 内部系统一般采用 Json 作为数据交换格式;系统间的互操作则采用XML 来规范；文本字符串是最一般的形式， 字节是最底层的形式。

JavaWeb应用开发框架实例

二、 架构演变

最轻的架构： jQuery + Servlet + ajax 在客户端使用 jQuery发送 ajax 请求给Java 服务端的 Servlet 进行处理， Servlet 仅仅返回数据给客户端进行渲染。

该架构有效地分离了前端展示和后台请求处理，同时又保持了最轻的复杂性， 只需要学会编写 Servlet 及使用 jQuery ， 就能构建简单的应用。

如果只是做个人创意演示， 可以采用该架构， 快速实现自己的创意功能。 Servlet 是Java web 应用的基础技术，jQuery 则是前端开发的简单易用的利器。

后台架构演变：

1. 逻辑与页面的分离： JSP/Servlet

JSP 实现了页面逻辑与外观的分离，但是， 前端子系统与后台子系统仍然是紧密耦合的; 前端设计人员实际上只需要服务端返回的数据， 就可设计出非常专业的界面显示。

2. MVC 架构：Struts2(含Servlet，MVC) + JDBC

用Servlet 来添加服务器功能是基本的选择，但在web.xml中配置大量的 Servlet 却不是最佳的选择。

Struts2 在服务端实现了更丰富的MVC 模式， 将本来由应用决定的控制器从web容器中分离。

3. SSH 架构： Struts2(含Servlet, MVC) + Spring (Ioc) + Hibernate (ORM，对象-关系映射)

通常， 应用系统中需要预先创建一些单例对象， 比如 Controller, Service, Dao, 线程池等， 可以引入 Spring Ioc 来有效地创建、管理和推送这些对象；使用 Hibernate 来实现关系数据库的行与面向对象的属性之间的映射与联接，以更好地简化和管理应用系统的数据库操作。SSH 可以说是 JavaWeb应用系统开发的三剑客。

4. SI 架构： SpringMVC(含Servlet, Ioc, MVC, Rest) + iBatis (Semi-ORM)

过于复杂的架构会将人搞晕。因此，在适应需求的情况下， 尽量选择简单的架构，是明智之选。 这种架构使用面向资源的理念，着重使用Spring作为MVC及应用基础服务设施， 同时使用 iBatis 来实现更简单灵活的ORM映射， 使之在可以理解和维护的范围内。

前端架构：

1. Flash 架构： Flex + jQuery + JSP

这是一种比较传统的前端架构，采用同步模式， Flex 承担大量的页面渲染工作， 并采用AMF协议与Java端进行通信， 而JSP 则可以用于更快速的页面显示。优点是： 经过考验的结构， 通常是值得信赖的; 缺点是， 由于采用同步模式， 在交互效果上可能不够流畅， 需要进行比较耗时的编译过程；此外， Flex 基于浏览器插件运行，在调试方面有些麻烦。

2. MVC 架构： Extjs + jQuery

这是一种比较现代的前端架构， 采用异步模式， Extjs4 可以实现前端子系统的MVC 分离， 对于可维护性是非常不错的支持；此外， jQuery 可以作为有效的补充。

优点： 异步， 快速， 对于企业内部的后台管理系统是非常好的选择。

缺点： Extjs4 的可定制性、可适应性可能难以适应各种特殊的需求，需要用其它组件来补充， 比如大数据量的绘制。对于互联网应用， 速度可能是致命伤。

三、 架构的选择

不要去询问哪种架构更好，更需要做的是清晰地定位项目目标，根据自己的具体情况来选择和定制架构。反复地尝试、观察和改进，反复磨炼技艺，这样才有助于设计水平的提升。

架构的选择通常有四种关注点：

1. 适用性： 是否适合你的项目需求。 架构有大有小， 小项目用小架构， 大项目用大架构。

2. 可扩展性： 该架构在需要添加新功能时，是否能够以常量的成本添加到现有系统中， 所做的改动在多大程度上会影响现有功能的实现(基本不影响，还是要大面积波及)。

3. 便利性： 使用该架构是否易于开发功能和扩展功能， 学习、开发和测试成本有多大。

4. 复杂性： 使用该架构后，维护起来的成本有多大。你自然希望能够写一条语句做很多事，使用各种成熟的组件是正确的方式，同时，在项目中混杂各种组件，也会提升理解和维护系统的复杂度。便利性和复杂性需要达到较好的平衡。

特殊的关注点：

譬如，应用需要支持高并发的情况， 需要建立一个底层的并发基础设施， 并向上层提供简单易用的接口，屏蔽其复杂性。

四、 架构演进的基本手段

架构并不是一成不变的， 在做出最初的架构之后，随着开发的具体情况和需求的变更， 需要对最初架构做出变更和改进。

架构演进的基本手段：

一致性， 隔离与统一管理， 螺旋式重构改进， 消除重复， 借鉴现有方案。

1. 一致性： 确保使用统一模式来处理相同或相似的功能; 解决一次， 使用多次。

2. 模块化、隔离与统一管理： 对于整体的应用， 分而治之，将其划分为隔离性良好的模块，提供必要的通信耦合;对于特定的功能模块， 采用隔离手段，将其隔离在局部统一管理，避免分散在系统的各处。

3. 不断重构改进， 一旦发现更好的方式， 马上替换掉原有方式。

4. 尽可能重用，消除重复。

5. 尽可能先借鉴系统中已有方案并复用之；如果有更好方案可替换之;

有一条设计准则是： 预先设计， 但不要过早设计。

意思是说， 需要对需求清楚的部分进行仔细的设计， 但是对于未知不清楚的需求，要坚持去理解它，但不要过早地去做出“预测性设计”；设计必须是明确的、清晰的、有效的， 不能针对含糊的东西来设计。可以在后期通过架构演进来获得对后续需求的适应能力。

编译：伯乐在线 - 范琦琦

死锁是两个甚至多个线程被永久阻塞时的一种运行局面，这种局面的生成伴随着至少两个线程和两个或者多个资源。在这里我已写好一个简单的程序，它将会引起死锁方案然后我们就会明白如何分析它。

Java死锁范例

ThreadDeadlock.java

package com.journaldev.threads;

public class ThreadDeadlock {

public static void main(String[] args) throws InterruptedException {

Object obj1 = new Object();

Object obj2 = new Object();

Object obj3 = new Object();

Thread t1 = new Thread(new SyncThread(obj1, obj2), "t1");

Thread t2 = new Thread(new SyncThread(obj2, obj3), "t2");

Thread t3 = new Thread(new SyncThread(obj3, obj1), "t3");

t1.start();

Thread.sleep(5000);

t2.start();

Thread.sleep(5000);

t3.start();

}

}

class SyncThread implements Runnable{

private Object obj1;

private Object obj2;

public SyncThread(Object o1, Object o2){

this.obj1=o1;

this.obj2=o2;

}

@Override

public void run() {

String name = Thread.currentThread().getName();

System.out.println(name + " acquiring lock on "+obj1);

synchronized (obj1) {

System.out.println(name + " acquired lock on "+obj1);

work();

System.out.println(name + " acquiring lock on "+obj2);

synchronized (obj2) {

System.out.println(name + " acquired lock on "+obj2);

work();

}

System.out.println(name + " released lock on "+obj2);

}

System.out.println(name + " released lock on "+obj1);

System.out.println(name + " finished execution.");

}

private void work() {

try {

Thread.sleep(30000);

} catch (InterruptedException e) {

e.printStackTrace();

}

}

}

在上面的程序中同步线程正完成Runnable的接口，它工作的是两个对象，这两个对象向对方寻求死锁而且都在使用同步阻塞。

在主函数中，我使用了三个为同步线程运行的线程，而且在其中每个线程中都有一个可共享的资源。

这些线程以向第一个对象获取封锁这种方式运行。但是当它试着像第二个对象获取封锁时，它就会进入等待状态，因为它已经被另一个线程封锁住了。这样，在线程引起死锁的过程中，就形成了一个依赖于资源的循环。

当我执行上面的程序时，就产生了输出，但是程序却因为死锁无法停止。

t1 acquiring lock on java.lang.Object@6d9dd520

t1 acquired lock on java.lang.Object@6d9dd520

t2 acquiring lock on java.lang.Object@22aed3a5

t2 acquired lock on java.lang.Object@22aed3a5

t3 acquiring lock on java.lang.Object@218c2661

t3 acquired lock on java.lang.Object@218c2661

t1 acquiring lock on java.lang.Object@22aed3a5

t2 acquiring lock on java.lang.Object@218c2661

t3 acquiring lock on java.lang.Object@6d9dd520

在此我们可以清楚地在输出结果中辨认出死锁局面，但是在我们实际生活所用的应用中，发现死锁并将它排除是非常难的。

分析死锁

为了分析一个死锁，我们需要关注下应用中的Java线程转存，在上一节中我已经解释了如何使用VisualVM收集资料或者jstack应用程序产生线程转存。

以下就是上述程序的线程转存。

2012-12-27 19:08:34

Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode):

"Attach Listener" daemon prio=5 tid=0x00007fb0a2814000 nid=0x4007 waiting on condition [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"DestroyJavaVM" prio=5 tid=0x00007fb0a2801000 nid=0x1703 waiting on condition [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"t3" prio=5 tid=0x00007fb0a204b000 nid=0x4d07 waiting for monitor entry [0x000000015d971000]

java.lang.Thread.State: BLOCKED (on object monitor)

at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)

- waiting to lock <0x000000013df2f658> (a java.lang.Object)

- locked <0x000000013df2f678> (a java.lang.Object)

at java.lang.Thread.run(Thread.java:722)

"t2" prio=5 tid=0x00007fb0a1073000 nid=0x4207 waiting for monitor entry [0x000000015d209000]

java.lang.Thread.State: BLOCKED (on object monitor)

at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)

- waiting to lock <0x000000013df2f678> (a java.lang.Object)

- locked <0x000000013df2f668> (a java.lang.Object)

at java.lang.Thread.run(Thread.java:722)

"t1" prio=5 tid=0x00007fb0a1072000 nid=0x5503 waiting for monitor entry [0x000000015d86e000]

java.lang.Thread.State: BLOCKED (on object monitor)

at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)

- waiting to lock <0x000000013df2f668> (a java.lang.Object)

- locked <0x000000013df2f658> (a java.lang.Object)

at java.lang.Thread.run(Thread.java:722)

"Service Thread" daemon prio=5 tid=0x00007fb0a1038000 nid=0x5303 runnable [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=5 tid=0x00007fb0a1037000 nid=0x5203 waiting on condition [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=5 tid=0x00007fb0a1016000 nid=0x5103 waiting on condition [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=5 tid=0x00007fb0a4003000 nid=0x5003 runnable [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=5 tid=0x00007fb0a4800000 nid=0x3f03 in Object.wait() [0x000000015d0c0000]

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

- waiting on <0x000000013de75798> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)

- locked <0x000000013de75798> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)

at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)

"Reference Handler" daemon prio=5 tid=0x00007fb0a4002000 nid=0x3e03 in Object.wait() [0x000000015cfbd000]

java.lang.Thread.State: WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

- waiting on <0x000000013de75320> (a java.lang.ref.Reference$Lock)

at java.lang.Object.wait(Object.java:503)

at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)

- locked <0x000000013de75320> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=5 tid=0x00007fb0a2049800 nid=0x3d03 runnable

"GC task thread#0 (ParallelGC)" prio=5 tid=0x00007fb0a300d800 nid=0x3503 runnable

"GC task thread#1 (ParallelGC)" prio=5 tid=0x00007fb0a2001800 nid=0x3603 runnable

"GC task thread#2 (ParallelGC)" prio=5 tid=0x00007fb0a2003800 nid=0x3703 runnable

"GC task thread#3 (ParallelGC)" prio=5 tid=0x00007fb0a2004000 nid=0x3803 runnable

"GC task thread#4 (ParallelGC)" prio=5 tid=0x00007fb0a2005000 nid=0x3903 runnable

"GC task thread#5 (ParallelGC)" prio=5 tid=0x00007fb0a2005800 nid=0x3a03 runnable

"GC task thread#6 (ParallelGC)" prio=5 tid=0x00007fb0a2006000 nid=0x3b03 runnable

"GC task thread#7 (ParallelGC)" prio=5 tid=0x00007fb0a2006800 nid=0x3c03 runnable

"VM Periodic Task Thread" prio=5 tid=0x00007fb0a1015000 nid=0x5403 waiting on condition

JNI global references: 114

Found one Java-level deadlock:

=============================

"t3":

waiting to lock monitor 0x00007fb0a1074b08 (object 0x000000013df2f658, a java.lang.Object),

which is held by "t1"

"t1":

waiting to lock monitor 0x00007fb0a1010f08 (object 0x000000013df2f668, a java.lang.Object),

which is held by "t2"

"t2":

waiting to lock monitor 0x00007fb0a1012360 (object 0x000000013df2f678, a java.lang.Object),

which is held by "t3"

Java stack information for the threads listed above:

===================================================

"t3":

at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)

- waiting to lock <0x000000013df2f658> (a java.lang.Object)

- locked <0x000000013df2f678> (a java.lang.Object)

at java.lang.Thread.run(Thread.java:722)

"t1":

at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)

- waiting to lock <0x000000013df2f668> (a java.lang.Object)

- locked <0x000000013df2f658> (a java.lang.Object)

at java.lang.Thread.run(Thread.java:722)

"t2":

at com.journaldev.threads.SyncThread.run(ThreadDeadlock.java:41)

- waiting to lock <0x000000013df2f678> (a java.lang.Object)

- locked <0x000000013df2f668> (a java.lang.Object)

at java.lang.Thread.run(Thread.java:722)

Found 1 deadlock.

这三个线程转存的输出清楚地说明了死锁环境和线程，以及包含死锁环境的资源。

为了分析死锁，我们需要关注死锁状态的线程，然后资源再等待去封锁，每一个资源都有一个独特的ID，有了这个ID我们就能发现是哪一个进程已经封锁住对象。举个例子，线程“t3”正在等待封锁0x000000013df2f658,但是它已经被线程“t1”封锁住了。

当我们分析死锁环境的时候，如果发现线程正在引起死锁，这是我们就要改变代码来避免死锁的产生。

避免死锁

有很多方针可供我们使用来避免死锁的局面。

避免嵌套封锁：这是死锁最主要的原因的，如果你已经有一个资源了就要避免封锁另一个资源。如果你运行时只有一个对象封锁，那是几乎不可能出现一个死锁局面的。例如，这里是另一个运行中没有嵌套封锁的run()方法，而且程序运行没有死锁局面，运行得很成功。

public void run() {

String name = Thread.currentThread().getName();

System.out.println(name + " acquiring lock on " + obj1);

synchronized (obj1) {

System.out.println(name + " acquired lock on " + obj1);

work();

}

System.out.println(name + " released lock on " + obj1);

System.out.println(name + " acquiring lock on " + obj2);

synchronized (obj2) {

System.out.println(name + " acquired lock on " + obj2);

work();

}

System.out.println(name + " released lock on " + obj2);

System.out.println(name + " finished execution.");

}

只对有请求的进行封锁：你应当只想你要运行的资源获取封锁，比如在上述程序中我在封锁的完全的对象资源。但是如果我们只对它所属领域中的一个感兴趣，那我们应当封锁住那个特殊的领域而并非完全的对象。

避免无限期的等待：如果两个线程正在等待对象结束，无限期的使用线程加入，如果你的线程必须要等待另一个线程的结束，若是等待进程的结束加入最好准备最长时间。

看完本文有收获？请转发分享给更多人

关注「ImportNew」，提升Java技能