Action是单实例还是多实例，为什么？
答：struts2中action是多例的，即一个session产生一个action
背景:
1) Struts2会对每一个请求,产生一个Action的实例来处理.
2) Spring的Ioc容器管理的bean默认是单实例的.
首先从数据安全性的问题上考虑，我们的Action应该保证是多例的，这样才不会出现数据问题。但是如果有的action比如只有admin才能操作，或者某些action，全站公用一个来提高性能，这样的话，就可以使用单例模式。
不过幸好，Spring的bean可以针对每一个设置它的scope，所以，上面的问题就不是问题了。如果用单例，就在spring的action bean配置的时候设置scope=”prototype”
如果是单例的话,若出现两个用户都修改一个对象的属性值,则会因为用户修改时间不同,两个用户访问得到的属性不一样,操作得出的结果不一样.
举个例子:有一块布长度300cm,能做一件上衣(用掉100cm)和一件裤子(用掉200cm);甲和乙同时访问得到的长度都是300cm,
甲想做上衣和裤子,他先截取100cm去做上衣,等上衣做完再去做裤子,而乙这时正好也拿100cm去做上衣,那好,等甲做完上衣再做裤子的时候发现剩下的布(100cm)已经不够做裤子了…..这就是影响系统的性能,解决的办法就是给甲和乙一人一块300cm的布,就不会出现布被别人偷用的事情,也是就单实例和多实例的区别
如果设置成单例，那么多个线程会共享一个ActionContext和ValueStack，这样并发访问的时候就会出现问题了
struts 2的Action是多实例的并非单例，也就是每次请求产生一个Action的对象。原因是：struts 2的Action中包含数据，例如你在页面填写的数据就会包含在Action的成员变量里面。如果Action是单实例的话，这些数据在多线程的环境下就会相互影响，例如造成别人填写的数据被你看到了。所以Struts2的Action是多例模式的。
问题出现了，可以让Struts2的action变成单例模式么？
Struts2中，可以使用注解开发,在Action上@Scope(“prototype”) 指定为多例 , 默认为singleton()单例)
基本上action的scope需要是prototype，就是每次请求都建立新的线程
不写的话，默认是singleton了
写一个单例类
答：单例模式主要作用是保证在Java应用程序中，一个类只有一个实例存在。下面给出两种不同形式的单例：
第一种形式：饿汉式单例
|
第二种形式：懒汉式单例
|
单例的特点：外界无法通过构造器来创建对象，该类必须提供一个静态方法向外界提供该类的唯一实例。
【补充】用Java进行服务器端编程时，使用单例模式的机会还是很多的，服务器上的资源都是很宝贵的，对于那些无状态的对象其实都可以单例化或者静态化（在内存中仅有唯一拷贝），如果使用了spring这样的框架来进行对象托管，Spring的IoC容器在默认情况下对所有托管对象都是进行了单例化处理的。
424.说说你所熟悉或听说过的设计模式以及你对设计模式的看法
答：在GoF的《Design Patterns: Elements of Reusable Object-Oriented Software》中给出了三类（创建型[对类的实例化过程的抽象化]、结构型[描述如何将类或对象结合在一起形成更大的结构]、行为型[对在不同的对象之间划分责任和算法的抽象化]）共23种设计模式，包括：Abstract Factory（抽象工厂模式），Builder（建造者模式），Factory Method（工厂方法模式），Prototype（原始模型模式），Singleton（单例模式）；Facade（门面模式），Adapter（适配器模式），Bridge（桥梁模式），Composite（合成模式），Decorator（装饰模式），Flyweight（享元模式），Proxy（代理模式）；Command（命令模式），Interpreter（解释器模式），Visitor（访问者模式），Iterator（迭代子模式），Mediator（调停者模式），Memento（备忘录模式），Observer（观察者模式），State（状态模式），Strategy（策略模式），Template Method（模板方法模式）， Chain Of Responsibility（责任链模式）。
所谓设计模式，就是一套被反复使用的代码设计经验的总结（情境中一个问题经过证实的一个解决方案）。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式使人们可以更加简单方便的复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。
【补充】设计模式并不是像某些地方吹嘘的那样是遥不可及的编程理念，说白了设计模式就是对面向对象的编程原则的实践，面向对象的编程原则包括：
单一职责原则：一个类只做它该做的事情。（单一职责原则想表达的就是“高内聚”，写代码最终极的原则只有六个字“高内聚、低耦合”，就如同葵花宝典或辟邪剑谱的中心思想就八个字“欲练此功必先自宫”，所谓的高内聚就是一个代码模块只完成一项功能，在面向对象中，如果只让一个类完成它该做的事，而不涉及与它无关的领域就是践行了高内聚的原则，这个类就只有单一职责。我们都知道一句话叫“因为专注，所以专业”，一个对象如果承担太多的职责，那么注定它什么都做不好。这个世界上任何好的东西都有两个特征，一个是功能单一，好的相机绝对不是电视购物里面卖的那种一个机器有一百多种功能的，它基本上只能照相；另一个是模块化，好的自行车是组装车，从减震叉、刹车到变速器，所有的部件都是可以拆卸和重新组装的，好的乒乓球拍也不是成品拍，一定是底板和胶皮可以拆分和自行组装的，一个好的软件系统，它里面的每个功能模块也应该是可以轻易的拿到其他系统中使用的，这样才能实现软件复用的目标。）
开闭原则：软件实体应当对扩展开放，对修改关闭。（在理想的状态下，当我们需要为一个软件系统增加新功能时，只需要从原来的系统派生出一些新类就可以，不需要修改原来的任何一行代码。要做到开闭有两个要点：①抽象是关键，一个系统中如果没有抽象类或接口系统就没有扩展点；②封装可变性，将系统中的各种可变因素封装到一个继承结构中，如果多个可变因素混杂在一起，系统将变得复杂而换乱，如果不清楚如何封装可变性，可以参考《设计模式精解》一书中对桥梁模式的讲解的章节。）
依赖倒转原则：面向接口编程。（该原则说得直白和具体一些就是声明方法的参数类型、方法的返回类型、变量的引用类型时，尽可能使用抽象类型而不用具体类型，因为抽象类型可以被它的任何一个子类型所替代，请参考下面的里氏替换原则。）
里氏替换原则：任何时候都可以用子类型替换掉父类型。（关于里氏替换原则的描述，Barbara Liskov女士的描述比这个要复杂得多，但简单的说就是能用父类型的地方就一定能使用子类型。里氏替换原则可以检查继承关系是否合理，如果一个继承关系违背了里氏替换原则，那么这个继承关系一定是错误的，需要对代码进行重构。例如让猫继承狗，或者狗继承猫，又或者让正方形继承长方形都是错误的继承关系，因为你很容易找到违反里氏替换原则的场景。需要注意的是：子类一定是增加父类的能力而不是减少父类的能力，因为子类比父类的能力更多，把能力多的对象当成能力少的对象来用当然没有任何问题。）
接口隔离原则：接口要小而专，绝不能大而全。（臃肿的接口是对接口的污染，既然接口表示能力，那么一个接口只应该描述一种能力，接口也应该是高度内聚的。例如，琴棋书画就应该分别设计为四个接口，而不应设计成一个接口中的四个方法，因为如果设计成一个接口中的四个方法，那么这个接口很难用，毕竟琴棋书画四样都精通的人还是少数，而如果设计成四个接口，会几项就实现几个接口，这样的话每个接口被复用的可能性是很高的。Java中的接口代表能力、代表约定、代表角色，能否正确的使用接口一定是编程水平高低的重要标识。）
合成聚合复用原则：优先使用聚合或合成关系复用代码。（通过继承来复用代码是面向对象程序设计中被滥用得最多的东西，因为所有的教科书都无一例外的对继承进行了鼓吹从而误导了初学者，类与类之间简单的说有三种关系，IS-A关系、HAS-A关系、USE-A关系，分别代表继承、关联和依赖。其中，关联关系根据其关联的强度又可以进一步划分为关联、聚合和合成，但说白了都是HAS-A关系，合成聚合复用原则想表达的是优先考虑HAS-A关系而不是IS-A关系复用代码，原因嘛可以自己从百度上找到一万个理由，需要说明的是，即使在Java的API中也有不少滥用继承的例子，例如Properties类继承了Hashtable类，Stack类继承了Vector类，这些继承明显就是错误的，更好的做法是在Properties类中放置一个Hashtable类型的成员并且将其键和值都设置为字符串来存储数据，而Stack类的设计也应该是在Stack类中放一个Vector对象来存储数据。记住：任何时候都不要继承工具类，工具是可以拥有并可以使用的（HAS/USE），而不是拿来继承的。）
迪米特法则：迪米特法则又叫最少知识原则，一个对象应当对其他对象有尽可能少的了解。（迪米特法则简单的说就是如何做到“低耦合”，门面模式和调停者模式就是对迪米特法则的践行。对于门面模式可以举一个简单的例子，你去一家公司洽谈业务，你不需要了解这个公司内部是如何运作的，你甚至可以对这个公司一无所知，去的时候只需要找到公司入口处的前台美女，告诉她们你要做什么，她们会找到合适的人跟你接洽，前台的美女就是公司这个系统的门面。再复杂的系统都可以为用户提供一个简单的门面，Java Web开发中作为前端控制器的Servlet或Filter不就是一个门面吗，浏览器对服务器的运作方式一无所知，但是通过前端控制器就能够根据你的请求得到相应的服务。调停者模式也可以举一个简单的例子来说明，例如一台计算机，CPU、内存、硬盘、显卡、声卡各种设备需要相互配合才能很好的工作，但是如果这些东西都直接连接到一起，计算机的布线将异常复杂，在这种情况下，主板作为一个调停者的身份出现，它将各个设备连接在一起而不需要每个设备之间直接交换数据，这样就减小了系统的耦合度和复杂度。迪米特法则用通俗的话来将就是不要和陌生人打交道，如果真的需要，找一个自己的朋友，让他替你和陌生人打交道。）
Java企业级开发中常用的设计模式有哪些？
答： 按照分层开发的观点，可以将应用划分为：表示层、业务逻辑层和持久层，每一层都有属于自己类别的设计模式。
表示层设计模式：
1) Interceptor Filter：拦截过滤器，提供请求预处理和后处理的方案，可以对请求和响应进行过滤。/p>
2) Front Controller：通过中央控制器提供请求管理和处理，管理内容读取、安全性、视图管理和导航等功能。Struts 2中的StrutsPrepareAndExecuteFilter、Spring MVC中的DispatcherServlet都是前端控制器，后者如下图所示：
3) View Helper：视图帮助器，负责将显示逻辑和业务逻辑分开。显示的部分放在视图组件中，业务逻辑代码放在帮助器中，典型的功能是内容读取、验证与适配。
4) Composite View：复合视图。
业务逻辑层设计模式：
1) Business Delegate：业务委托，减少表示层和业务逻辑层之间的耦合。
2) Value Object：值对象，解决层之间交换数据的开销问题。
3) Session Façade：会话门面，隐藏业务逻辑组件的细节，集中工作流程。
4) Value Object Assembler：灵活的组装不同的值对象
5) Value List Handler：提供执行查询和处理结果的解决方案，还可以缓存查询结果，从而达到提升性能的目的。
6) Service Locator：服务定位器，可以查找、创建和定位服务工厂，封装其实现细节，减少复杂性，提供单个控制点，通过缓存提高性能。
持久层设计模式：
Data Access Object：数据访问对象，以面向对象的方式完成对数据的增删改查。
【补充】如果想深入的了解Java企业级应用的设计模式和架构模式，可以参考这些书籍： 《Pro Java EE Spring Patterns》、《POJO in Action》、《Patterns of Enterprise Application Architecture》。
