java面试

摘要：面向切面编程的目标就是分离关注点。不会出现数据不一致或者数据污染。线程不安全就是不提供数据访问保护，有可能出现多个线程先后更改数据造成所得到的数据是脏数据和区别是的轻量级实现非线程安全的实现

我们用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（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送上门来。
   形象的举例就是：
    通常情况下，假如你有一天在家里口渴了，要喝水，那么你可以到你小区的小卖部去，告诉他们，你需要一瓶水，然后小卖部给你一瓶水！这本来没有太大问题，
    关键是如果小卖部很远，那么你必须知道：从你家如何到小卖部；小卖部里是否有你需要的水；你还要考虑是否开着车去；等等等等，也许有太多的问题要考虑了。
    也就是说，为了一瓶水，你还可能需要依赖于车等等这些交通工具或别的工具，问题是不是变得复杂了？那么如何解决这个问题呢？
    解决这个问题的方法很简单：小卖部提供送货上门服务，凡是小卖部的会员，你只要告知小卖部你需要什么，小卖部将主动把货物给你送上门来！这样一来，你只需要做两件事情，你就可以活得更加轻松自在：
    第一：向小卖部注册为会员。
    第二：告诉小卖部你需要什么。
    

面向切面编程的目标就是分离关注点。什么是关注点呢？就是你要做的事，就是关点。假如你是个公子哥，没啥人生目标，天天就是衣来伸手，饭来张口，整天只知道玩一件事！那么，每天你一睁眼，就光想着吃完饭就去玩（你必须要做的事），
但是在玩之前，你还需要穿衣服、穿鞋子、叠好被子、做饭等等等等事情，这些事情就是你的关注点，但是你只想吃饭然后玩，那么怎么办呢？这些事情通通交给别人去干。在你走到饭桌之前，有一个专门的仆人A帮你穿衣服，仆人B帮你穿鞋子，仆人C帮你叠好被子，仆人C帮你做饭，然后你就开始吃饭、去玩（这就是你一天的正事），你干完你的正事之后，回来，然后一系列仆人又开始帮你干这个干那个，然后一天就结束了！
AOP的好处就是你只需要干你的正事，其它事情别人帮你干。也许有一天，你想裸奔，不想穿衣服，那么你把仆人A解雇就是了！也许有一天，出门之前你还想带点钱，那么你再雇一个仆人D专门帮你干取钱的活！这就是AOP。每个人各司其职，灵活组合，达到一种可配置的、可插拔的程序结构。
从Spring的角度看，AOP最大的用途就在于提供了事务管理的能力。事务管理就是一个关注点，你的正事就是去访问数据库，而你不想管事务（太烦），所以，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
    -----List        List接口中的对象按一定顺序排列，允许重复
               -----LinkedList    非同步
                ----ArrayList      非同步，实现了可变大小的元素数组
                ----Vector          同步   线程安全
                         ------Stack
    -----Set   不允许有相同的元素
         Set接口中的对象没有顺序，但是不允许重复 


Map               Map接口中的对象是key、value的映射关系，key不允许重复
    -----HashTable        同步，实现一个key--value映射的哈希表  线程安全
    -----HashMap          非同步，
    -----WeakHashMap   改进的HashMap，实现了“弱引用”，如果一个key不被引用，则被GC回收
    

  线程安全就是多线程访问时，采用了加锁机制，当一个线程访问该类的某个数据时，进行保护，
其他线程不能进行访问直到该线程读取完，其他线程才可使用。不会出现数据不一致或者数据污染。
  线程不安全就是不提供数据访问保护，有可能出现多个线程先后更改数据
造成所得到的数据是脏数据

  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进行改动。而辐射式设计，比如某个电梯都装了某种报警器，一旦要更新报警器，就必须全部更新。也就是说对于抽象类，如果需要添加新的方法，可以直接在抽象类中添加具体的实现，子类可以不进行变更；而对于接口则不行，如果接口进行了变更，则所有实现这个接口的类都必须进行相应的改动。