阿里巴巴电面整理(二)

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

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

• 请说一下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发上来，要的朋友就拿去吧。

    

评论

50 楼 davidwang456 2010-09-17  

楼主 用心良苦呀 赞扬一下 

49 楼 BloodyCoder 2010-09-13  

ninja9turtle 写道

kimmking 写道

sdh5724 写道

ninja9turtle 写道

kimmking 写道

ninja9turtle 写道

招聘版面竟然有这么多篇关于阿里的帖子，这一年似乎阿里和淘宝越来越多自我宣传的味道，网站、书刊、博客和围脖到处都能听到自诩某某架构师的称谓，并且将自己在公司的不满宣泄于公众，某某架构师不服某某架构师，某某架构师的架构不被采纳，我呆过两家八十年代就起家的软硬件公司，也未见几个敢称呼自己为架构师的，看看这种根本不能测出人的自学素质的面试题又不知处于哪位“架构师”之手。

阿里淘宝产品市场做的不错，但技术远未为优秀，希望能少听见写年轻架构师的张狂，多出点能走向世界的优秀产品。

浮夸哪里都是有的，
但是技术能手自称架构师未必不可，经验见识和能力俱佳者众矣

人类创造这么多词汇就是用来区别交流之用，好比小孩、青年、成人、老人，如果技术能手都成为架构师，那基本上公司里负责界面的、DB的、通讯的、安全的、业务的、售前售后的每个人在自己岗位熟悉各一年半载的都能成为技术能手，岂不全公司都是**架构师了，如果年龄称呼只有老小之别那人与人之间就无法更好的沟通交流，如果一个公司只有新员工和架构师两个称呼，那还如何定岗、定薪、定责。

也许我属于比较老一代的程序员，在我们那个年代走过来的公司里面架构师是责任很重的甚至有些神圣的味道，当然这种称谓没有个精确定义，个人看法而已，如果阿里里面所有人都觉得大部分技术熟练手都称呼为架构师合情合理俺也无权干涉。

我怎么没有见到啊， 见到了， 我也嘲讽XXX架构师。 哈哈， 兄台言之犀利，不过， “年轻架构师的张狂” 这在哪儿发出的感慨呢， 偶也瞧瞧。

才高八斗，张狂也是个性。胸无点墨，张狂自是无知。
不过说实在的，个人以为ali的人里，在自己的领域内，功底深厚的能力还是有不少的。

金山和永中一直号称自己的office如何功力不浅，如何超越微软，我不能扁他没技术没架构师，不能扁他没有中国政府采购市场，当我更希望他们能自己走出国门，让老外承认他们的优秀而不是自己在家里号称***

诺不是阿里我也不想多说，多少年国内有多少有潜力成为世界级的优秀软件公司的一个个倒下，本人泼点冷水也是为了阿里淘宝能走得更好，我不再争论阿里到底有多少打架构师，到底功底深厚到何程度，当你走出国门做得世界优秀时再来扁我也不迟，当然到时你也不屑扁我了，我的目的也达到了。

阿里的成功是商业模式的成功，跟技术有什么关系！

48 楼 huchangyue 2010-09-13  

楼主发的题目，我都全部做了一边答案，虽说是基础，但要全部答对，还是得有非常深的内功！帖子不错，分析得也不错。支持

47 楼 ninja9turtle 2010-07-07  

kimmking 写道

sdh5724 写道

ninja9turtle 写道

kimmking 写道

ninja9turtle 写道

招聘版面竟然有这么多篇关于阿里的帖子，这一年似乎阿里和淘宝越来越多自我宣传的味道，网站、书刊、博客和围脖到处都能听到自诩某某架构师的称谓，并且将自己在公司的不满宣泄于公众，某某架构师不服某某架构师，某某架构师的架构不被采纳，我呆过两家八十年代就起家的软硬件公司，也未见几个敢称呼自己为架构师的，看看这种根本不能测出人的自学素质的面试题又不知处于哪位“架构师”之手。

阿里淘宝产品市场做的不错，但技术远未为优秀，希望能少听见写年轻架构师的张狂，多出点能走向世界的优秀产品。

浮夸哪里都是有的，
但是技术能手自称架构师未必不可，经验见识和能力俱佳者众矣

人类创造这么多词汇就是用来区别交流之用，好比小孩、青年、成人、老人，如果技术能手都成为架构师，那基本上公司里负责界面的、DB的、通讯的、安全的、业务的、售前售后的每个人在自己岗位熟悉各一年半载的都能成为技术能手，岂不全公司都是**架构师了，如果年龄称呼只有老小之别那人与人之间就无法更好的沟通交流，如果一个公司只有新员工和架构师两个称呼，那还如何定岗、定薪、定责。

也许我属于比较老一代的程序员，在我们那个年代走过来的公司里面架构师是责任很重的甚至有些神圣的味道，当然这种称谓没有个精确定义，个人看法而已，如果阿里里面所有人都觉得大部分技术熟练手都称呼为架构师合情合理俺也无权干涉。

我怎么没有见到啊， 见到了， 我也嘲讽XXX架构师。 哈哈， 兄台言之犀利，不过， “年轻架构师的张狂” 这在哪儿发出的感慨呢， 偶也瞧瞧。

才高八斗，张狂也是个性。胸无点墨，张狂自是无知。
不过说实在的，个人以为ali的人里，在自己的领域内，功底深厚的能力还是有不少的。

金山和永中一直号称自己的office如何功力不浅，如何超越微软，我不能扁他没技术没架构师，不能扁他没有中国政府采购市场，当我更希望他们能自己走出国门，让老外承认他们的优秀而不是自己在家里号称***

诺不是阿里我也不想多说，多少年国内有多少有潜力成为世界级的优秀软件公司的一个个倒下，本人泼点冷水也是为了阿里淘宝能走得更好，我不再争论阿里到底有多少打架构师，到底功底深厚到何程度，当你走出国门做得世界优秀时再来扁我也不迟，当然到时你也不屑扁我了，我的目的也达到了。

46 楼 sdh5724 2010-07-07  

其实，　我倒是觉得架构师多点好。　能提升程序员的地位以及待遇。　当然，　每个人的看法是不同的，　争论多了，　自然，　理就明了了。有一个合适的title是对程序员的尊重，　无论我们提倡怎么样的公平也好，　需要什么样的味道也好，　提升能力＆获得尊重是每个程序员都渴望的。　凡事都有其两面性。　

45 楼 kimmking 2010-07-06  

sdh5724 写道

ninja9turtle 写道

kimmking 写道

ninja9turtle 写道

招聘版面竟然有这么多篇关于阿里的帖子，这一年似乎阿里和淘宝越来越多自我宣传的味道，网站、书刊、博客和围脖到处都能听到自诩某某架构师的称谓，并且将自己在公司的不满宣泄于公众，某某架构师不服某某架构师，某某架构师的架构不被采纳，我呆过两家八十年代就起家的软硬件公司，也未见几个敢称呼自己为架构师的，看看这种根本不能测出人的自学素质的面试题又不知处于哪位“架构师”之手。

阿里淘宝产品市场做的不错，但技术远未为优秀，希望能少听见写年轻架构师的张狂，多出点能走向世界的优秀产品。

浮夸哪里都是有的，
但是技术能手自称架构师未必不可，经验见识和能力俱佳者众矣

人类创造这么多词汇就是用来区别交流之用，好比小孩、青年、成人、老人，如果技术能手都成为架构师，那基本上公司里负责界面的、DB的、通讯的、安全的、业务的、售前售后的每个人在自己岗位熟悉各一年半载的都能成为技术能手，岂不全公司都是**架构师了，如果年龄称呼只有老小之别那人与人之间就无法更好的沟通交流，如果一个公司只有新员工和架构师两个称呼，那还如何定岗、定薪、定责。

也许我属于比较老一代的程序员，在我们那个年代走过来的公司里面架构师是责任很重的甚至有些神圣的味道，当然这种称谓没有个精确定义，个人看法而已，如果阿里里面所有人都觉得大部分技术熟练手都称呼为架构师合情合理俺也无权干涉。

我怎么没有见到啊， 见到了， 我也嘲讽XXX架构师。 哈哈， 兄台言之犀利，不过， “年轻架构师的张狂” 这在哪儿发出的感慨呢， 偶也瞧瞧。

才高八斗，张狂也是个性。胸无点墨，张狂自是无知。
不过说实在的，个人以为ali的人里，在自己的领域内，功底深厚的能力还是有不少的。

44 楼 kimmking 2010-07-06  

ninja9turtle 写道

kimmking 写道

ninja9turtle 写道

招聘版面竟然有这么多篇关于阿里的帖子，这一年似乎阿里和淘宝越来越多自我宣传的味道，网站、书刊、博客和围脖到处都能听到自诩某某架构师的称谓，并且将自己在公司的不满宣泄于公众，某某架构师不服某某架构师，某某架构师的架构不被采纳，我呆过两家八十年代就起家的软硬件公司，也未见几个敢称呼自己为架构师的，看看这种根本不能测出人的自学素质的面试题又不知处于哪位“架构师”之手。

阿里淘宝产品市场做的不错，但技术远未为优秀，希望能少听见写年轻架构师的张狂，多出点能走向世界的优秀产品。

浮夸哪里都是有的，
但是技术能手自称架构师未必不可，经验见识和能力俱佳者众矣

人类创造这么多词汇就是用来区别交流之用，好比小孩、青年、成人、老人，如果技术能手都成为架构师，那基本上公司里负责界面的、DB的、通讯的、安全的、业务的、售前售后的每个人在自己岗位熟悉各一年半载的都能成为技术能手，岂不全公司都是**架构师了，如果年龄称呼只有老小之别那人与人之间就无法更好的沟通交流，如果一个公司只有新员工和架构师两个称呼，那还如何定岗、定薪、定责。

也许我属于比较老一代的程序员，在我们那个年代走过来的公司里面架构师是责任很重的甚至有些神圣的味道，当然这种称谓没有个精确定义，个人看法而已，如果阿里里面所有人都觉得大部分技术熟练手都称呼为架构师合情合理俺也无权干涉。

抠字眼没有意义的。

人人都是项目经理，但未必都是合格的项目经理。
人人都是架构师，但未必都是合格的架构师。

个人以为架构师确实有神圣的意味，但是绝不应该跟定岗定薪挂钩。
架构师应该是能手，能手未必是称职的架构师。

43 楼 ninja9turtle 2010-07-06  

sdh5724 写道

ninja9turtle 写道

kimmking 写道

ninja9turtle 写道

招聘版面竟然有这么多篇关于阿里的帖子，这一年似乎阿里和淘宝越来越多自我宣传的味道，网站、书刊、博客和围脖到处都能听到自诩某某架构师的称谓，并且将自己在公司的不满宣泄于公众，某某架构师不服某某架构师，某某架构师的架构不被采纳，我呆过两家八十年代就起家的软硬件公司，也未见几个敢称呼自己为架构师的，看看这种根本不能测出人的自学素质的面试题又不知处于哪位“架构师”之手。

阿里淘宝产品市场做的不错，但技术远未为优秀，希望能少听见写年轻架构师的张狂，多出点能走向世界的优秀产品。

浮夸哪里都是有的，
但是技术能手自称架构师未必不可，经验见识和能力俱佳者众矣

人类创造这么多词汇就是用来区别交流之用，好比小孩、青年、成人、老人，如果技术能手都成为架构师，那基本上公司里负责界面的、DB的、通讯的、安全的、业务的、售前售后的每个人在自己岗位熟悉各一年半载的都能成为技术能手，岂不全公司都是**架构师了，如果年龄称呼只有老小之别那人与人之间就无法更好的沟通交流，如果一个公司只有新员工和架构师两个称呼，那还如何定岗、定薪、定责。

也许我属于比较老一代的程序员，在我们那个年代走过来的公司里面架构师是责任很重的甚至有些神圣的味道，当然这种称谓没有个精确定义，个人看法而已，如果阿里里面所有人都觉得大部分技术熟练手都称呼为架构师合情合理俺也无权干涉。

我怎么没有见到啊， 见到了， 我也嘲讽XXX架构师。 哈哈， 兄台言之犀利，不过， “年轻架构师的张狂” 这在哪儿发出的感慨呢， 偶也瞧瞧。

指名点姓固然伤人，兄台你search一把“淘宝 阿里 架构师”搜索巨人自然会给你答案，俺并不是扁阿里无牛人，任何一个公司能存活下来自然有其顶梁的团队人才

42 楼 sdh5724 2010-07-06  

ninja9turtle 写道

kimmking 写道

ninja9turtle 写道

招聘版面竟然有这么多篇关于阿里的帖子，这一年似乎阿里和淘宝越来越多自我宣传的味道，网站、书刊、博客和围脖到处都能听到自诩某某架构师的称谓，并且将自己在公司的不满宣泄于公众，某某架构师不服某某架构师，某某架构师的架构不被采纳，我呆过两家八十年代就起家的软硬件公司，也未见几个敢称呼自己为架构师的，看看这种根本不能测出人的自学素质的面试题又不知处于哪位“架构师”之手。

阿里淘宝产品市场做的不错，但技术远未为优秀，希望能少听见写年轻架构师的张狂，多出点能走向世界的优秀产品。

浮夸哪里都是有的，
但是技术能手自称架构师未必不可，经验见识和能力俱佳者众矣

人类创造这么多词汇就是用来区别交流之用，好比小孩、青年、成人、老人，如果技术能手都成为架构师，那基本上公司里负责界面的、DB的、通讯的、安全的、业务的、售前售后的每个人在自己岗位熟悉各一年半载的都能成为技术能手，岂不全公司都是**架构师了，如果年龄称呼只有老小之别那人与人之间就无法更好的沟通交流，如果一个公司只有新员工和架构师两个称呼，那还如何定岗、定薪、定责。

也许我属于比较老一代的程序员，在我们那个年代走过来的公司里面架构师是责任很重的甚至有些神圣的味道，当然这种称谓没有个精确定义，个人看法而已，如果阿里里面所有人都觉得大部分技术熟练手都称呼为架构师合情合理俺也无权干涉。

我怎么没有见到啊， 见到了， 我也嘲讽XXX架构师。 哈哈， 兄台言之犀利，不过， “年轻架构师的张狂” 这在哪儿发出的感慨呢， 偶也瞧瞧。

41 楼 ninja9turtle 2010-07-06  

kimmking 写道

ninja9turtle 写道

招聘版面竟然有这么多篇关于阿里的帖子，这一年似乎阿里和淘宝越来越多自我宣传的味道，网站、书刊、博客和围脖到处都能听到自诩某某架构师的称谓，并且将自己在公司的不满宣泄于公众，某某架构师不服某某架构师，某某架构师的架构不被采纳，我呆过两家八十年代就起家的软硬件公司，也未见几个敢称呼自己为架构师的，看看这种根本不能测出人的自学素质的面试题又不知处于哪位“架构师”之手。

阿里淘宝产品市场做的不错，但技术远未为优秀，希望能少听见写年轻架构师的张狂，多出点能走向世界的优秀产品。

浮夸哪里都是有的，
但是技术能手自称架构师未必不可，经验见识和能力俱佳者众矣

人类创造这么多词汇就是用来区别交流之用，好比小孩、青年、成人、老人，如果技术能手都成为架构师，那基本上公司里负责界面的、DB的、通讯的、安全的、业务的、售前售后的每个人在自己岗位熟悉各一年半载的都能成为技术能手，岂不全公司都是**架构师了，如果年龄称呼只有老小之别那人与人之间就无法更好的沟通交流，如果一个公司只有新员工和架构师两个称呼，那还如何定岗、定薪、定责。

也许我属于比较老一代的程序员，在我们那个年代走过来的公司里面架构师是责任很重的甚至有些神圣的味道，当然这种称谓没有个精确定义，个人看法而已，如果阿里里面所有人都觉得大部分技术熟练手都称呼为架构师合情合理俺也无权干涉。

40 楼 kimmking 2010-07-06  

ninja9turtle 写道

招聘版面竟然有这么多篇关于阿里的帖子，这一年似乎阿里和淘宝越来越多自我宣传的味道，网站、书刊、博客和围脖到处都能听到自诩某某架构师的称谓，并且将自己在公司的不满宣泄于公众，某某架构师不服某某架构师，某某架构师的架构不被采纳，我呆过两家八十年代就起家的软硬件公司，也未见几个敢称呼自己为架构师的，看看这种根本不能测出人的自学素质的面试题又不知处于哪位“架构师”之手。

阿里淘宝产品市场做的不错，但技术远未为优秀，希望能少听见写年轻架构师的张狂，多出点能走向世界的优秀产品。

浮夸哪里都是有的，
但是技术能手自称架构师未必不可，经验见识和能力俱佳者众矣

39 楼 ninja9turtle 2010-07-06  

招聘版面竟然有这么多篇关于阿里的帖子，这一年似乎阿里和淘宝越来越多自我宣传的味道，网站、书刊、博客和围脖到处都能听到自诩某某架构师的称谓，并且将自己在公司的不满宣泄于公众，某某架构师不服某某架构师，某某架构师的架构不被采纳，我呆过两家八十年代就起家的软硬件公司，也未见几个敢称呼自己为架构师的，看看这种根本不能测出人的自学素质的面试题又不知处于哪位“架构师”之手。

阿里淘宝产品市场做的不错，但技术远未为优秀，希望能少听见写年轻架构师的张狂，多出点能走向世界的优秀产品。

38 楼 luckaway 2010-07-06  

sdh5724 写道

我想打面试官。 具体的开源产品提问， 很伤人。

看看框架的源码还是不错的，设计思想以及类、方法的命名方式都值的借鉴的！

37 楼 sdh5724 2010-07-06  

我想打面试官。 具体的开源产品提问， 很伤人。

36 楼 linking12 2010-07-06  

好人。。。

35 楼 topcode 2010-07-06  

scope="prototype"

34 楼 holly2k 2010-07-05  

忘了说了，因为spring默认都是单例的，因此在配置struts2的时候需要加配置不以单例形式实例化，呵呵

33 楼 holly2k 2010-07-05  

struts1中的action是单例的，因为数据存储是使用actionForm来存储的，action单例即可，struts2中的action是多例的，因为此时struts是将页面表单数据存在action的域里，如果是单例的话势必造成数据混乱，另外不是做广告，在传智上的视频讲解struts的时候就有说到这个问题，因为看的时候距离现在有点时间了，也不太清楚是struts1还是struts2的时候讲的

32 楼 zjf_1103 2010-07-05  

网址的后缀是.aspx?,楼主你取个名字也太累了吧.action或者.do蛮好的呀，呵呵

31 楼 piao_bo_yi 2010-07-05  

<div class="quote_title">starfeng 写道</div>
<div class="quote_div">
<div class="quote_title">gogole_09 写道</div>
<div class="quote_div">对于这点的原因，我还是没有弄清楚，为什么按照第2种方式配置，不用指定scope，就会自动的为每个action创建一个实例？(希望懂的朋友，可以指点指点)</div>
<p> </p>
<p>struts2与spring集成通过plugin "struts2-spring"实现, 这个插件提供了一个新的对象工厂: org.apache.struts2.spring.StrutsSpringObjectFactory, 并且, 它通过struts.objectFactory=spring来激活这个新的工厂.</p>
<p>当struts2要创建action时, 通过如下方式切入到spring:</p>
<p>buildAction--&gt;buildBean--&gt;</p>
<p>try {<br>    o = appContext.getBean(beanName);  // 注1: 有正确配置的情况下,在这里结束new instance<br>} catch (NoSuchBeanDefinitionException e) {  // 注2: 在spring找不到相关配置时,它又转入了默认的struts构建方式<br>    Class beanClazz = getClassInstance(beanName);<br>    o = buildBean(beanClazz, extraContext);<br>}</p>
<p>--&gt;</p>
<p>bean = autoWiringFactory.autowire(clazz, AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR, false);</p>
<p>所以, 你第二次方式做的, 每次都会建新的实例.</p>
<p> </p>
<p>但, 我要说明一点的是, 第二种方式是一种相对低效的方式, 即然用spring就全部用spring的方式去配你的action比较好.</p>
<p> </p>
<div class="quote_title">gogole_09 写道</div>
<div class="quote_div">我们都知道线程安全是指什么，我的理解是， 当一个类的“状态”（实例变量）被多个线程所修改时，<br><br>那么这个类的状态的“正确”性得不到保证，我们就可以理解成线程安全出现。<br><br><br>当然，如果一个没有状态的类，那么它永远都是线程安全的。<br><br><br><br>再深入一点来看， 我们从Java虚拟机的层面来看这个问题，答案就很明朗了：<br>Java 程序在运行时创建的所有类实例或数组，都存放在同一个堆中，而一个JVM实例中只存在一个堆空间，<br><br>因此，它被所有的线程共享着，这样的情况下，就可能出现，多个线程访问对象（堆数据）的同步问题了。</div>
<p> </p>
<p>虽然你这里看起来每句话都是对的, 但却又有点没解释到根本上.</p>
<p>类的状态...你发明了一个不太好的词, "当一个类的“状态”（实例变量）被多个线程所修改时",  漏洞有点多, 多个实例呢, 这个状态怎么算? 通常我们只会说实例的状态.</p>
<p>换个说法可能更好理解一点: <strong>同一实例</strong>的属性<strong>同时</strong>被<strong>多个</strong>线程<strong>修改</strong> (注意不是调用)</p>
<p> </p>
<p>所以,</p>
<p>实例没属性,自然也没法被"<strong>修改</strong>", 自然也是线程安全</p>
<p>每个实例只被一个线程修改(也即每个线程自已创建实例), 自然没法被"<strong>多个</strong>", 也是线程安全</p>
<p>加上同步关键字, 没法被"<strong>同时</strong>", 自然也是线程安全 </p>
<p>采用锁, 没法被"<strong>同时</strong>", 也是线程安全</p>
<p>...</p>
<p> </p>
<p>深入部份你这讲了一半, 还有另一半:</p>
<p>深入JVM去理解, 要抛开OO, 抛开public, private之类, 不然, 你会想当然的认为某些安全是理所当然的.</p>
<p>比方, 为什么方法内的东西就是线程安全? 如下:</p>
<p>public void method() {</p>
<p>    int i = 0;</p>
<p>    i = i + 1;</p>
<p>}</p>
<p>凭什么 i = i + 1就会一定由0变成1, 而不是由0变成2或3...</p>
<p>当然, 本身原因也简单, 只不过不要从public/private的角度去理解为: 外部访问不到所以安全. 要知道jvm这个层面是没有这个东西的.</p>
<p> </p>
<p>首先,JVM中只有一块堆也只有一块栈,所以"一块"不是全不安全的理由, 其原因在用法上面.</p>
<p>在某一时刻,实例有属性状态,方法运行状态, 属性的放堆, 方法的放栈.</p>
<p>方法的运行在栈中, 多个方法的同时运行要依靠多个线程(这里不讨论进程), 而线程为保证方法相互不干扰, 会为每个方法开辟独立的栈区, 即压栈. 因而对于方法来说, 都在属于某一线程所在的栈中,因为方法间不会相互干扰, 因而没有线程问题.  虽然没有线程问题, 但是呢, 线程间也没法通过栈来沟通信息.</p>
<p>实例属性, 就有点不同了, 每个线程不会再copy一份新的, 多个线程会共用同一个, 所以, 线程问题就出来了. </p>
<p> </p>
<p>不想再深讲下去了, 感觉后面的话题一问接一问可以深太入太多. 有兴趣的看大学教材的线程部份,以及网上找文章JVM字节码相关部份.</p>
</div>
<p>顶～～建议LZ看看基础知识。个人感觉应该是实际经验有，个人思考有，但是基础的并发相关概念不是很明白。</p>