spingmvc 和 structs的区别
我们用struts2时采用的传统的配置文件的方式，并没有使用传说中的0配置。
spring3 mvc可以认为已经100%零配置了（除了配置spring mvc-servlet.xml外）。
Spring MVC和Struts2的区别：
1. 机制：spring mvc的入口是servlet，而struts2是filter（这里要指出，filter和servlet是不同的。以前认为filter是servlet的一种特殊），这样就导致了二者的机制不同，这里就牵涉到servlet和filter的区别了。
2. 性能：spring会稍微比struts快。spring mvc是基于方法的设计，而sturts是基于类，每次发一次请求都会实例一个action，每个action都会被注入属性.
而spring基于方法，粒度更细，但要小心把握像在servlet控制数据一样。spring3 mvc是方法级别的拦截，拦截到方法后根据参数上的注解，把request数据注入进去，在spring3 mvc中，一个方法对应一个request上下文。
而struts2框架是类级别的拦截，每次来了请求就创建一个Action，然后调用setter getter方法把request中的数据注入；struts2实际上是通过setter getter方法与request打交道的；struts2中，一个Action对象对应一个request上下文。
3. 参数传递：struts是在接受参数的时候，可以用属性来接受参数，这就说明参数是让多个方法共享的。
4. 设计思想上：struts更加符合oop的编程思想， spring就比较谨慎，在servlet上扩展。
5. intercepter的实现机制：struts有以自己的interceptor机制，spring mvc用的是独立的AOP方式。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继承，所以我觉得论使用上来讲，spring mvc使用更加简洁，开发效率Spring MVC确实比struts2高。
spring mvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应，所以说从架构本身上spring3 mvc就容易实现restful url。
struts2是类级别的拦截，一个类对应一个request上下文；实现restful url要费劲，因为struts2 action的一个方法可以对应一个url；而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。
spring3 mvc的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架方法之间不共享变量，而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码，读程序时带来麻烦。
6. 另外，spring3 mvc的验证也是一个亮点，支持JSR303，处理ajax的请求更是方便，只需一个注解@ResponseBody ，然后直接返回响应文本即可。
IOC
IOC（Inverse of Control）：控制反转，也可以称为依赖倒置。
所谓依赖，从程序的角度看，就是比如A要调用B的方法，那么A就依赖于B，反正A要用到B，则A依赖于B。所谓倒置，你必须理解如果不倒置，会怎么着，因为A必须要有B，才可以调用B，
如果不倒置，意思就是A主动获取B的实例：B b = new B()，这就是最简单的获取B实例的方法（当然还有各种设计模式可以帮助你去获得B的实例，比如工厂、Locator等等），然后你就可以调用b对象了。
所以，不倒置，意味着A要主动获取B，才能使用B；到了这里，就应该明白了倒置的意思了。倒置就是A要调用B的话，A并不需要主动获取B，而是由其它人自动将B送上门来。
形象的举例就是：
通常情况下，假如你有一天在家里口渴了，要喝水，那么你可以到你小区的小卖部去，告诉他们，你需要一瓶水，然后小卖部给你一瓶水！这本来没有太大问题，
关键是如果小卖部很远，那么你必须知道：从你家如何到小卖部；小卖部里是否有你需要的水；你还要考虑是否开着车去；等等等等，也许有太多的问题要考虑了。
也就是说，为了一瓶水，你还可能需要依赖于车等等这些交通工具或别的工具，问题是不是变得复杂了？那么如何解决这个问题呢？
解决这个问题的方法很简单：小卖部提供送货上门服务，凡是小卖部的会员，你只要告知小卖部你需要什么，小卖部将主动把货物给你送上门来！这样一来，你只需要做两件事情，你就可以活得更加轻松自在：
第一：向小卖部注册为会员。
第二：告诉小卖部你需要什么。
AOP
面向切面编程的目标就是分离关注点。什么是关注点呢？就是你要做的事，就是关点。假如你是个公子哥，没啥人生目标，天天就是衣来伸手，饭来张口，整天只知道玩一件事！那么，每天你一睁眼，就光想着吃完饭就去玩（你必须要做的事），
但是在玩之前，你还需要穿衣服、穿鞋子、叠好被子、做饭等等等等事情，这些事情就是你的关注点，但是你只想吃饭然后玩，那么怎么办呢？这些事情通通交给别人去干。在你走到饭桌之前，有一个专门的仆人A帮你穿衣服，仆人B帮你穿鞋子，仆人C帮你叠好被子，仆人C帮你做饭，然后你就开始吃饭、去玩（这就是你一天的正事），你干完你的正事之后，回来，然后一系列仆人又开始帮你干这个干那个，然后一天就结束了！
AOP的好处就是你只需要干你的正事，其它事情别人帮你干。也许有一天，你想裸奔，不想穿衣服，那么你把仆人A解雇就是了！也许有一天，出门之前你还想带点钱，那么你再雇一个仆人D专门帮你干取钱的活！这就是AOP。每个人各司其职，灵活组合，达到一种可配置的、可插拔的程序结构。
从Spring的角度看，AOP最大的用途就在于提供了事务管理的能力。事务管理就是一个关注点，你的正事就是去访问数据库，而你不想管事务（太烦），所以，Spring在你访问数据库之前，自动帮你开启事务，当你访问数据库结束之后，自动帮你提交/回滚事务！
Spring 事务管理
Spring配置文件中关于事务配置总是由三个组成部分，分别是DataSource,TransactionManager和代理机制这三部分，无论哪种配置方式，一般变化的只是代理机制这部分。
缓存技术
可做缓存的技术，Ehcache, Linkedhashmap, Memcached, Redis，视需求而定
LinkedHashMap 和Ehcache都是单机缓存技术，即只能在一个应用内实现缓存，
不能实现多台机器使用相同的缓存区域（分布式缓存）
LinkedHashMap的底层是用HashMap实现的，特点元素的排序是按链表方式
排序，按写入或输出的顺序排序，最后一次写入或读取的元素放到最后
LinkedHashMap 只是一个JDK自带的类，而Ehcache是一个外部jar包，是Java领域常用的缓存框架，
鼎鼎大名的hibernate都是用Ehcache，但ehcache也可用使用某些技术支持在群集环境中使用
Memcached是分布式缓存技术，需要独立部署，使多台机器
可以使用同一个缓存服务器，实现集群的缓存共享。
Redis同样是分布式缓存技术，比Memcached更新，支持的数据类型更多，使用更方便，最
重要的是：Memcached的数据只能存在内存中，重启后即消失，而Redis可以持久化，因此
Redis可以作为一个NoSql数据库使用。如果没有历史遗留系统，初次引入缓存框架，建议用redis
反射机制
反射机制其实就是指程序在运行的时候能够获取自身的信息。
如果知道一个类的名称/或者它的一个实例对象，就能把这个类的所有方法和
变量的信息(方法名，变量名，方法，修饰符，类型，方法参数等等所有信息)找出来。
如果明确知道这个类里的某个方法名+参数个数 类型，还能通过传递参数来运行那个类里的那个方法，这就是反射。
优缺点
反射的优点当然是体现在它的动态性上面，能运行时确定类型，绑定对象。
动态编译最大限度发挥了java的灵活性，体现了多态的应用，
降低类之间的藕合性。 一句话，反射机制的优点就是可以实现动态创建对象和编译，
特别是在J2EE的开发中，它的灵活性就表现的十分明显。比如，一个大型的软件，不可能一次就把 它设计的很完美，
当这个程序编译后，发布了，当发现需要更新某些功能时，我们不可能要用户把以前的卸载，
再重新安装新的版本，假如这样的话，这个软件肯定 是没有多少人用的。
采用静态的话，需要把整个程序重新编译一次才可以实现功能的更新，而采用反射机制的话，它就可以不用卸载，
只需要在运行时才动态的创建 和编译，就可以实现该功能。
它的缺点是对性能有影响。使用反射基本上是一种解释操作，
我们可以告诉JVM，我们希望做什么并且它满足我们的要求。这类操作总是慢于只直接执行相同的操作
Collection Map
Collection Map
Collection
-----List List接口中的对象按一定顺序排列，允许重复
-----LinkedList 非同步
----ArrayList 非同步，实现了可变大小的元素数组
----Vector 同步 线程安全
------Stack
-----Set 不允许有相同的元素
Set接口中的对象没有顺序，但是不允许重复
Map Map接口中的对象是key、value的映射关系，key不允许重复
-----HashTable 同步，实现一个key--value映射的哈希表 线程安全
-----HashMap 非同步，
-----WeakHashMap 改进的HashMap，实现了“弱引用”，如果一个key不被引用，则被GC回收
线程安全和线程不安全
线程安全就是多线程访问时，采用了加锁机制，当一个线程访问该类的某个数据时，进行保护，
其他线程不能进行访问直到该线程读取完，其他线程才可使用。不会出现数据不一致或者数据污染。
线程不安全就是不提供数据访问保护，有可能出现多个线程先后更改数据
造成所得到的数据是脏数据
hashMap和hashTable区别
HashMap是Hashtable的轻量级实现（非线程安全的实现），他们都完成了Map接口，
主要区别在于HashMap允许空（null）键值（key）,由于非线程安全，效率上可能高于Hashtable。
HashMap允许将null作为一个entry的key或者value，而Hashtable不允许。
HashMap把Hashtable的contains方法去掉了，改成containsvalue和containsKey。
因为contains方法容易让人引起误解。
Hashtable继承自Dictionary类，而HashMap是Java1.2引进的Map interface的一个实现。
最大的不同是，Hashtable的方法是Synchronize的，而HashMap不是，在多个线程访问Hashtable时，不需要
自己为它的方法实现同步，而HashMap 就必须为之提供外同步(Collections.synchronizedMap)。
Hashtable和HashMap采用的hash/rehash算法都大概一样，所以性能不会有很大的差异。
接口和抽象类
1.语法层面上的区别
1）抽象类可以提供成员方法的实现细节，而接口中只能存在public abstract 方法；
2）抽象类中的成员变量可以是各种类型的，而接口中的成员变量只能是public static final类型的；
3）接口中不能含有静态代码块以及静态方法，而抽象类可以有静态代码块和静态方法；
4）一个类只能继承一个抽象类，而一个类却可以实现多个接口。
2.设计层面上的区别
1）抽象类是对一种事物的抽象，即对类抽象，而接口是对行为的抽象。抽象类是对整个类整体进行抽象，包括属性、行为，但是接口却是对类局部（行为）进行抽象。举个简单的例子，飞机和鸟是不同类的事物，但是它们都有一个共性，就是都会飞。那么在设计的时候，可以将飞机设计为一个类Airplane，将鸟设计为一个类Bird，但是不能将 飞行 这个特性也设计为类，因此它只是一个行为特性，并不是对一类事物的抽象描述。此时可以将 飞行 设计为一个接口Fly，包含方法fly( )，然后Airplane和Bird分别根据自己的需要实现Fly这个接口。然后至于有不同种类的飞机，比如战斗机、民用飞机等直接继承Airplane即可，对于鸟也是类似的，不同种类的鸟直接继承Bird类即可。从这里可以看出，继承是一个 "是不是"的关系，而 接口 实现则是 "有没有"的关系。如果一个类继承了某个抽象类，则子类必定是抽象类的种类，而接口实现则是有没有、具备不具备的关系，比如鸟是否能飞（或者是否具备飞行这个特点），能飞行则可以实现这个接口，不能飞行就不实现这个接口。
2）设计层面不同，抽象类作为很多子类的父类，它是一种模板式设计。而接口是一种行为规范，它是一种辐射式设计。什么是模板式设计？最简单例子，大家都用过ppt里面的模板，如果用模板A设计了ppt B和ppt C，ppt B和ppt C公共的部分就是模板A了，如果它们的公共部分需要改动，则只需要改动模板A就可以了，不需要重新对ppt B和ppt C进行改动。而辐射式设计，比如某个电梯都装了某种报警器，一旦要更新报警器，就必须全部更新。也就是说对于抽象类，如果需要添加新的方法，可以直接在抽象类中添加具体的实现，子类可以不进行变更；而对于接口则不行，如果接口进行了变更，则所有实现这个接口的类都必须进行相应的改动。
