1.tomact6.0 跟 tomact5.0的区别
Tomcat6.x在目录上最大的区别就是将 lib 包直接置于 CATALINA_HOME/lib 下，而tomcat 5.x 系列版本是分common/share/server 三个包存放的。再具体解释一下：
CATALINA_HOME/common
在这个目录下的lib目录，存放Tomcat 服务器和所有Web应用都能访问的JAR.
CATALINA_HOME/share
在这个目录下的lib目录，存放所有Web应用都能访问的，但Tomcat 不能访问的JAR。
CATALINA_HOME/server
在这个目录下的lib目录，存放Tomcat 服务器需要的但Web应用不能访问的JAR。
另外该目录下webapps 存放Tomcat 自带的APP-admin和manager两个应用。
common/share/server 三个包中的classes是用来存放class的，就是说你的类库不打成JAR包，而是class文件就直接放在这里。
Tomcat 6.x 在目录结构上就是针对lib包的存放位置做了调整，使应用部署更加方便。另外：
Tomcat 6.x中endorsed 从CATALINA_HOME/common移到根目录下了CATALINA_HOME\endorsed 至于其它没有太大的变化。
另外需要说明的是tomcat 5.x有目录CATALINA_HOME\conf\Catalina\localhost
在Tomcat 6.x中该目录是空的就没给你建，你可以自己建。有好几个朋友问我这个问题了，这里给你提醒一下。
至于xml文件我还没有注意到有什么变化，以后发现了大家在讨论。
2.collections他实现的接口，跟类有哪些，画图。
3.jdk1.5新特性
泛型（Generics）--为集合（collections）提供编译时类型安全，无需每刻从Collections取得一个对象就进行强制转换（cast）
增强的“for”循环（Enhanced For loop）--减少迭代器(iterator)的潜在错误（error-proneness）
自动置入/自动取出（Autoboxing/unboxing）--无需在基本类型（primitive types）（例如double）和包装类型（wrapper types）（例如Double）之间人工地进行转换。
类型安全的枚举（Typesafeenums）--提供类型安全枚举模式的各项好处。
静态导入（Static import）--无需在使用其他类的静态成员变量前缀其类名.这将使得代码更为简洁。
元数据（Metadata）--使编程人员避免编写样板化代码（boiler plate code），并提供机会进行宣告式程式设计(declarative programming)。
4.多线程为什么能同步,底层是怎样实现的
5.设计模式有哪些原则(单一职责,高类聚,低耦合，依赖倒置，里氏替换原则).
6.数据库优化有什么
7.jdbc的事物怎么控制(autocommit=false,不自动提交)
8.hibernate跟ibatis有是区别
9.tomact支持ejb吗
6.对做过的项目有整体的认识(用到什么技术ssh,(框架),什么技术难点，实现的细节是什么(远望谷股份公司))
1.当一个表非常大时，应该如何优化？
用索引，但是当索引也太大时应该怎么办？
历史归档
1.冗余表
2.历史数据归档
3.分区，拆表 ,分区表，看情况按条件分区 ,水平切分（时间维度或业务维度），垂直切分（业务维度细化）
4.按某种规则水平或垂直分表
5.分表：把一个大表按某个规则切分成N个小表，这样查就比较快。(像ORACL提供了分区功能，把数据放到不同的区上，就是分流作用。)
6.nosql,如果不需要transaction的话,Nosql（一致性要求）
7.最简单的是把过期的或不活动数据，迁移到一张历史表，现有表只放少量的活动数据。
M-S/RAC，读写分离.
2.聚集索引和非聚集索引的区别(sqlserver)
1.聚集索引和非聚集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致，
2.聚集索引：插入数据时速度要慢（时间花费在“物理存储的排序”上，也就是首先要找到位置然后插入）,查询数据比非聚集数据的速度快
3.sql的优化
1，索引的利用
2，分区的利用
3，查询的分离。有时一条sql语句不见得比多条sql语句来的高效
4，表结构的设计。
4.sql中为什么exist比in的效率高
1. exist 只要找到一个满足条件的记录就颠了，返回true
in 却要把结果集查出来，一个一个去比。
2. 如果子查询得出的结果集记录较少，主查询中的表较大且又有索引时应该用in, 反之如果外层的主查询记录较少，子查询中的表大，又有索引时使用exists
1.享元模式:普通的解决方案需要过多对象，产生普通对象太占空间时使用享元.
