阿里巴巴电面整理(二)

  还是接着昨天的帖子来吧， 题目都在上一篇《阿里巴巴电面整理》，

  昨天发的被管理员移到求职招聘区了，今天主动一点，自己移过来， 这次整理的东西比较少，但是也花了一点时间。

• 请说一下Struts2 是如何把Action交给Spring托管的？
  它是单例的还是多例？ 你们页面的表单对象是多例还是单例?

 首先，来看看如何让Spring 来管理Action.

1.在struts.xml中加入 <constant name="struts.objectFactory" value="spring"/> 
有两种整合方式：
     (1) 将Struts的业务逻辑控制器类配置在Spring的配置文件中，Action中引用的业务类一并注入。

                (这样的处理，必须将action类的scope配置成property)

<bean id="LoginAction" class="yaso.struts.action.LoginAction">
   <property name="loginDao" ref="LoginDao"/>
</bean> 

 接着，在struts.xml或者等效的Struts2配置文件中配置Action时，指定<action>的class属性为Spring配置文件中相应bean的id或者name值。示例如下： 
 

<action name=”LoginAction” class=”LoginAction”>
                     <result name=”success”>/index.jsp</result>
 </action> 

 

         (2) 业务类在Spring配置文件中配置，Action不需要配置，Struts2的Action像没有整合Spring之前一样配置，

           <action>的class属性指定业务逻辑控制器类的全限定名。  Action中引用的业务类不需要自己去初始化，

Struts2的Spring插件会使用bean的自动装配将业务类注入进来，其实Action也不是Struts2创建的，

而是Struts2的Spring插件创建的。默认情况下，插件使用by name的方式装配，

可以通过增加Struts2常量来修改匹配方式：设置方式

为：struts.objectFactory.spring.autoWire = typeName，

可选的装配参数如下：

name:相当于spring配置的autowrie="byName"(默认)
type:相当于spring配置的autowrie="byType"
auto:相当于spring 配置的autowrie="autodetect"
constructor: 相当于spring配置的autowrie="constructor"

           OK，这里说了配置部分，但是，这里有一个问题， 就是Spring管理Action，如果按照第一方式，那么只要通过  

           scope="property"来配置为每个请求创建一个Action实例。 那么第二种方式，我们并没有指定Action的作用域

          （好似也没有地方可配……），那么，这样的整合方式，Action的创建到底是单例还是多例的呢？
            答案也是每个请求一个实例，我这里通过一个很笨的办法，来证明它：

我会写一个Action的构造函数， 并在里面打上一句话，加入断点，如果说，每次请求都会进入断点，那么就意味着，每个请求都有一个新的实例是正确的。

第一次进入的时候，是在容器启动的时候：

 

第一次进入的时候，是在容器启动的时候：

 

 

我们请求Action:

 

再次进入断点，说明，每个请求都有一个Action实例来处理。 

 

对于这点的原因，我还是没有弄清楚，为什么按照第2种方式配置，不用指定scope，就会自动的为每个action创建一个实例？(希望懂的朋友，可以指点指点)

对于我们项目中的页面表单对象， 毫无疑问，它也是多例的.

• 请说一下Struts2源代码中有哪些设计模式？

简单罗列一下：
单例模式-- 典型应用： 类：
org.apache.struts2.config.ServletContextSingleton

 

模版方法模式：
  在org.apache.struts2.components包中大量运用

 

责任连模式：
 在拦截器部分使用.

•     请说一下线程安全出现的原因？

           我们都知道线程安全是指什么，我的理解是， 当一个类的“状态”（实例变量）被多个线程所修改时，

            那么这个类的状态的“正确”性得不到保证，我们就可以理解成线程安全出现。

            当然，如果一个没有状态的类，那么它永远都是线程安全的。

 

            再深入一点来看， 我们从Java虚拟机的层面来看这个问题，答案就很明朗了：
              Java程序在运行时创建的所有类实例或数组，都存放在同一个堆中，而一个JVM实例中只存在一个堆空间，

因此，它被所有的线程共享着，这样的情况下，就可能出现，多个线程访问对象（堆数据）的同步问题了。

 

请说一下线程池的中断策略(4个)？ 各有什么特点？

         这里所指的线程池是concurrent包中的ThreadPoolExecutor,而中断策略实际上是指饱和策略

           （concurent包中的RejectedExecutionHandler接口)，
             这里需要先解释一下，什么叫饱和策略， 实际就是说， 线程池中的线程容器已经放不下先的任务了，

             饱和了， 必须要有一个相应的策略来处理。
               ThreadPoolExecutor内部，已经定义了4种饱和策略：

          

 
 

默认的饱和策略是： （中止）， 既如果放不下了，既中止新加入的任务。

private static final RejectedExecutionHandler defaultHandler =new AbortPolicy(); 

 
源代码中调用如下

public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
        if (poolSize >= corePoolSize || !addIfUnderCorePoolSize(command)) {
            if (runState == RUNNING && workQueue.offer(command)) {
                if (runState != RUNNING || poolSize == 0)
                    ensureQueuedTaskHandled(command);
            }
            else if (!addIfUnderMaximumPoolSize(command))
                    //容不下新的任务了，默认是中止掉
                reject(command); // is shutdown or saturated
        }
    } 

如果需要设置饱和策略，可以调用ThreadPoolExecutor的setRejectExecutionHandler方法，

JDK提供了4种不同策略的实现(4种实现都定义在ThreadPoolExecutor类中，有兴趣可以查看一下源代码)：

下面介绍一下4种实现的特点：
AbortPolicy: （中止）它是默认的策略。
CallerRunsPolicy: (调用者运行), 它既不会丢弃任务，也不会抛出任何异常，它会把任务推回到调用者那里去,以此缓解任务流
DiscardPolicy: （遗弃）策略，它默认会放弃这个任务
DiscardOldestPolicy:（遗弃最旧的），它选择的丢弃的任务，是它本来要执行的（可怜的娃，就这样被新加入的给排挤了）,

 

 

 

/**
     * 饱和策略之----调用者运行策略
     */
public static class CallerRunsPolicy implements 
	RejectedExecutionHandler {
 public CallerRunsPolicy() { }
 public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
            if (!e.isShutdown()) {
                r.run();
            }
  }
}

    /**
     * 饱和策略之----中止（默认的）
     */
public static class AbortPolicy implements RejectedExecutionHandler {
        public AbortPolicy() { }

        /**
         * 直接抛异常，中止
         */
        public void rejectedExecution(Runnable r, 
                                        ThreadPoolExecutor e) {
            throw new RejectedExecutionException();
        }
    }

    /**
     * 饱和策略之----遗弃策略
     */
public static class DiscardPolicy implements ejectedExecutionHandler{
        
        public DiscardPolicy() { }

        /**
         * 不做任何处理，直接无视
         */
        public void rejectedExecution(Runnable r, 
                                      ThreadPoolExecutor e) {
        }
    }

    /**
     * 饱和策略之----遗弃最旧策略
     */
public static class DiscardOldestPolicy implements   
                                   RejectedExecutionHandler {
        public DiscardOldestPolicy() { }
        public void rejectedExecution(Runnable r,
                                       ThreadPoolExecutor e) {
        	//遗弃最旧的， 如果是用优先级队列存储池中的任务，
          //则会丢弃优先级最高的
            if (!e.isShutdown()) {
                e.getQueue().poll();//丢弃
                e.execute(r);//执行新任务
            }
        }
    }	

 

 

      到目前为止，题目差不多整理了2/3了， 基本上我在整理的同时有相当于复习了一遍。 很受用，当然，这些题目都是些基础知识， 帖子的本意并非是要炫耀什么，当然，我也没什么可炫耀的。 我的本意就是简单的知识共享，予人予己都有好处。 如果你觉得这贴对你没用，那就请直接无视吧……  

  

     帖子里面的题目都是先整理到word ，再发来je的，发发牢骚，JE的排版操作起来不容易呀，要是有直接从word里面导，该多好呀……， 这里我把Word发上来，要的朋友就拿去吧。

    

多谢lz花了这么多时间来整理，对我这样的菜鸟来说很受用。
祝lz顺利拿到offer！

LZ幸苦了，我对LZ的感激犹如滔滔江水绵绵不绝

这个struts的action必然是单例且不是线程安全的

这句话从何说起？ 望明示......

没什么可明示，单例性能会好很多，而且这也是我struts1的实践结果。

请问一下，从哪些方面可以看出单例性能会好很多。就是说每次的相同请求都是共用一个单例，不用产生更多的实例？？一般多例都是以牺牲空间换时间。

struts1的action本身就是单例而且就是线程不安全的。 不过帖子中谈的是Strust2的.

我是没有用过struts2，不过我个人觉得为了性能也不可能多例的