1、使用final关键字修饰一个变量时，是引用不能变，还是引用的对象不能变？
使用final关键字修饰一个变量时，是指引用变量不能变，引用变量所指向的对象中的内容还是可以改变的。例如，对于如下语句：
final StringBuffer a=new StringBuffer("immutable");
执行如下语句将报告编译期错误：
a=new StringBuffer("");
但是，执行如下语句则可以通过编译：
a.append(" broken!");
有人在定义方法的参数时，可能想采用如下形式来阻止方法内部修改传进来的参数对象：
publicvoid method(final StringBuffer param)
{
}
实际上，这是办不到的，在该方法内部仍然可以增加如下代码来修改参数对象：
param.append("a");
2、当一个线程进入一个对象的一个synchronized方法后，其它线程是否可进入此对象的其它方法?
分几种情况：
1.其他方法前是否加了synchronized关键字，如果没加，则能。
2.如果这个方法内部调用了wait，则可以进入其他synchronized方法。
3.如果其他个方法都加了synchronized关键字，并且内部没有调用wait，则不能。
4.如果其他方法是static，它用的同步锁是当前类的字节码，与非静态的方法不能同步，因为非静态的方法用的是this。
3、线程的基本概念、线程的基本状态以及状态之间的关系
一个程序中可以有多条执行线索同时执行，一个线程就是程序中的一条执行线索，每个线程上都关联有要执行的代码，即可以有多段程序代码同时运行，每个程序至少都有一个线程，即main方法执行的那个线程。如果只是一个cpu，它怎么能够同时执行多段程序呢？这是从宏观上来看的，cpu一会执行a线索，一会执行b线索，切换时间很快，给人的感觉是a,b在同时执行，好比大家在同一个办公室上网，只有一条链接到外部网线，其实，这条网线一会为a传数据，一会为b传数据，由于切换时间很短暂，所以，大家感觉都在同时上网。
状态：就绪，运行，synchronize阻塞，wait和sleep挂起，结束。wait必须在synchronized内部调用。
调用线程的start方法后线程进入就绪状态，线程调度系统将就绪状态的线程转为运行状态，遇到synchronized语句时，由运行状态转为阻塞，当synchronized获得锁后，由阻塞转为运行，在这种情况可以调用wait方法转为挂起状态，当线程关联的代码执行完后，线程变为结束状态。
4、简述synchronized和java.util.concurrent.locks.Lock的异同？
主要相同点：Lock能完成synchronized所实现的所有功能
主要不同点：Lock有比synchronized更精确的线程语义和更好的性能。synchronized会自动释放锁，而Lock一定要求程序员手工释放，并且必须在finally从句中释放。Lock还有更强大的功能，例如，它的tryLock方法可以非阻塞方式去拿锁。
举例说明（对下面的题用lock进行了改写）：
package com.huawei.interview;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
publicclass ThreadTest {
/**
*@paramargs
*/
private int j;
private Lock lock = new ReentrantLock();
publicstaticvoid main(String[] args) {
//TODO Auto-generatedmethod stub
ThreadTest tt = new ThreadTest();
for(int i=0;i<2;i++)
{
new Thread(tt.new Adder()).start();
new Thread(tt.new Subtractor()).start();
}
}
privateclass Subtractor implements Runnable
{
@Override
publicvoid run() {
//TODO Auto-generatedmethod stub
while(true)
{
/*synchronized(ThreadTest.this) {
System.out.println("j--=" + j--);
//这里抛异常了，锁能释放吗？
}*/
lock.lock();
try
{
System.out.println("j--=" +j--);
}finally
{
lock.unlock();
}
}
}
}
privateclass Adderimplements Runnable
{
@Override
publicvoid run() {
//TODO Auto-generatedmethod stub
while(true)
{
/*synchronized(ThreadTest.this) {
System.out.println("j++=" + j++);
}*/
lock.lock();
try
{
System.out.println("j++=" +j++);
}finally
{
lock.unlock();
}
}
}
}
}
5、List、Map、Set三个接口，存取元素时，各有什么特点？
这样的题属于随意发挥题：这样的题比较考水平，两个方面的水平：一是要真正明白这些内容，二是要有较强的总结和表述能力。如果你明白，但表述不清楚，在别人那里则等同于不明白。
首先，List与Set具有相似性，它们都是单列元素的集合，所以，它们有一个功共同的父接口，叫Collection。Set里面不允许有重复的元素，所谓重复，即不能有两个相等（注意，不是仅仅是相同）的对象，即假设Set集合中有了一个A对象，现在我要向Set集合再存入一个B对象，但B对象与A对象equals相等，则B对象存储不进去，所以，Set集合的add方法有一个boolean的返回值，当集合中没有某个元素，此时add方法可成功加入该元素时，则返回true，当集合含有与某个元素equals相等的元素时，此时add方法无法加入该元素，返回结果为false。Set取元素时，没法说取第几个，只能以Iterator接口取得所有的元素，再逐一遍历各个元素。
List表示有先后顺序的集合，注意，不是那种按年龄、按大小、按价格之类的排序。当我们多次调用add(Obj e)方法时，每次加入的对象就像火车站买票有排队顺序一样，按先来后到的顺序排序。有时候，也可以插队，即调用add(int
index,Obj e)方法，就可以指定当前对象在集合中的存放位置。一个对象可以被反复存储进List中，每调用一次add方法，这个对象就被插入进集合中一次，其实，并不是把这个对象本身存储进了集合中，而是在集合中用一个索引变量指向这个对象，当这个对象被add多次时，即相当于集合中有多个索引指向了这个对象，如图x所示。List除了可以以Iterator接口取得所有的元素，再逐一遍历各个元素之外，还可以调用get(indexi)来明确说明取第几个。
Map与List和Set不同，它是双列的集合，其中有put方法，定义如下：put(obj
key,obj value)，每次存储时，要存储一对key/value，不能存储重复的key，这个重复的规则也是按equals比较相等。取则可以根据key获得相应的value，即get(Object
key)返回值为key 所对应的value。另外，也可以获得所有的key的结合，还可以获得所有的value的结合，还可以获得key和value组合成的Map.Entry对象的集合。
List 以特定次序来持有元素，可有重复元素。Set无法拥有重复元素,内部排序。Map保存key-value值，value可多值。
HashSet按照hashcode值的某种运算方式进行存储，而不是直接按hashCode值的大小进行存储。例如，"abc"
---> 78，"def" ---> 62，"xyz" ---> 65在hashSet中的存储顺序不是62,65,78，这些问题感谢以前一个叫崔健的学员提出，最后通过查看源代码给他解释清楚，看本次培训学员当中有多少能看懂源码。LinkedHashSet按插入的顺序存储，那被存储对象的hashcode方法还有什么作用呢？学员想想!hashset集合比较两个对象是否相等，首先看hashcode方法是否相等，然后看equals方法是否相等。new两个Student插入到HashSet中，看HashSet的size，实现hashcode和equals方法后再看size。
同一个对象可以在Vector中加入多次。往集合里面加元素，相当于集合里用一根绳子连接到了目标对象。往HashSet中却加不了多次的。
6、谈谈你对Struts的理解。
答:
1. struts是一个按MVC模式设计的Web层框架，其实它就是一个大大的servlet，这个Servlet名为ActionServlet，或是ActionServlet的子类。我们可以在web.xml文件中将符合某种特征的所有请求交给这个Servlet处理，这个Servlet再参照一个配置文件（通常为/WEB-INF/struts-config.xml）将各个请求分别分配给不同的action去处理。
一个扩展知识点：struts的配置文件可以有多个，可以按模块配置各自的配置文件，这样可以防止配置文件的过度膨胀；
2.ActionServlet把请求交给action去处理之前，会将请求参数封装成一个formbean对象（就是一个java类，这个类中的每个属性对应一个请求参数），封装成一个什么样的formbean对象呢？看配置文件。
3.要说明的是， ActionServlet把formbean对象传递给action的execute方法之前，可能会调用formbean的validate方法进行校验，只有校验通过后才将这个formbean对象传递给action的execute方法，否则，它将返回一个错误页面，这个错误页面由input属性指定，（看配置文件）作者为什么将这里命名为input属性，而不是error属性，我们后面结合实际的运行效果进行分析。
4.action执行完后要返回显示的结果视图，这个结果视图是用一个ActionForward对象来表示的，actionforward对象通过struts-config.xml配置文件中的配置关联到某个jsp页面，因为程序中使用的是在struts-config.xml配置文件为jsp页面设置的逻辑名，这样可以实现action程序代码与返回的jsp页面名称的解耦。
7、Struts优缺点
优点：
1. 实现MVC模式，结构清晰,使开发者只关注业务逻辑的实现.
2．有丰富的tag可以用,Struts的标记库(Taglib)，如能灵活动用，则能大大提高开发效率
3. 页面导航
使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。
4. 提供Exception处理机制.
5. 数据库链接池管理
6. 支持I18N
缺点
一、 转到展示层时，需要配置forward，如果有十个展示层的jsp，需要配置十次struts，而且还不包括有时候目录、文件变更，需要重新修改forward，注意，每次修改配置之后，要求重新部署整个项目，而tomcate这样的服务器，还必须重新启动服务器
二、 二、Struts的Action必需是thread－safe方式，它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步，这个就引起了线程安全的问题。
三、 测试不方便.Struts的每个Action都同Web层耦合在一起，这样它的测试依赖于Web容器，单元测试也很难实现。不过有一个Junit的扩展工具Struts
TestCase可以实现它的单元测试。
四、 类型的转换.Struts的FormBean把所有的数据都作为String类型，它可以使用工具Commons-Beanutils进行类型转化。但它的转化都是在Class级别，而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。
五、 对Servlet的依赖性过强. Struts处理Action时必需要依赖ServletRequest和ServletResponse，所有它摆脱不了Servlet容器。
六、 前端表达式语言方面.Struts集成了JSTL，所以它主要使用JSTL的表达式语言来获取数据。可是JSTL的表达式语言在Collection和索引属性方面处理显得很弱。
七、 对Action执行的控制困难. Struts创建一个Action，如果想控制它的执行顺序将会非常困难。甚至你要重新去写Servlet来实现你的这个功能需求。
八、 对Action执行前和后的处理. Struts处理Action的时候是基于class的hierarchies，很难在action处理前和后进行操作。
九、 对事件支持不够.在struts中，实际是一个表单Form对应一个Action类(或DispatchAction)，换一句话说：在Struts中实际是一个表单只能对应一个事件，struts这种事件方式称为application
event，applicationevent和component event相比是一种粗粒度的事件
8、j2ee常用的设计模式？说明工厂模式。
总共23种，分为三大类：创建型，结构型，行为型
我只记得其中常用的6、7种，分别是：
创建型（工厂、工厂方法、抽象工厂、单例）建造者模式，原型模式
结构型（包装、适配器，组合，代理）桥接，外观，享元；
行为（观察者，模版，策略）责任链，命令，解释器，迭代器，中介者，备忘录，状态，访问者。
然后再针对你熟悉的模式谈谈你的理解即可。
Java中的23种设计模式：
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 Responsibleity（责任链模式）