今天受邀去参加了某个公司面试的第二轮复试，今天复试的是公司的一个项目主管，感觉比之前面试的更懂技术一些，还问了一些比较刁钻的问题，在这里记录一些自己的不足和自己觉得比较有价值的东西，作为自己的部分参考。
①关于docker和vmware优势 docker在磁盘空间上的节省不用说了，MB 与 GB的对比； VMware公司指出虚拟化会只会引入大约2%到4%的性能损失。在Docker容器中运行像Redis这样的应用程序，其性能是完全可以接受的，而其在安全、管理等方面的优势使得Docker容器成为虚拟化方面的推荐选择； Docker的简易性。“Docker为从根本上为简化和加快软件产品的构建提供了巨大的潜力”； docker其他的优势： 轻量级的隔离环境比虚拟机能够更方便和快捷地启动和停止； 可以在一个虚拟机中运行多个 container，从而节省开销； Docker 的 container 机制更适合一些持续集成/持续发布和微型 PaaS 场景。
②死锁和活锁 说实话，我当时自我感觉都死锁还是有一个较深入的了解，我把死锁对答如流的回答出来，不过到活锁的时候，我就显得有点蒙圈了，老实说，之前基本没听过还有活锁这一东西，于是回来google之，得出下列参考： 死锁：两个或者以上的进程（线程）在执行过程中，因争夺资源而造成的一种互相等待的现象，一直等待谁都没得到。 活锁：主要是多线程中，每个线程都很有礼貌，有风度，绅士，本来是可以使用资源的，但是总是礼貌的让给他人，导致最后也同样一个都没有拿到资源，执行下去。 另外延伸一个饥饿：1,2,3，4线程，简单的说就是1放了资源，这个时候系统不分给2，而是分给3，再分给4，再一直分给后来的，导致2这货一直拿不到资源，无法执行，一直等待下去（实际中，不一定是2，有可能有类似他一列一组的所有） 下面借鉴下http://www.cnblogs.com/ktgu/p/3529143.html的博客例子： 关于“死锁与活锁”的比喻： 死锁：迎面开来的汽车A和汽车B过马路，汽车A得到了半条路的资源（满足死锁发生条件1：资源访问是排他性的，我占了路你就不能上来，除非你爬我头上去），汽车B占了汽车A的另外半条路的资源，A想过去必须请求另一半被B占用的道路（死锁发生条件2：必须整条车身的空间才能开过去，我已经占了一半，尼玛另一半的路被B占用了），B若想过去也必须等待A让路，A是辆兰博基尼，B是开奇瑞QQ的屌丝，A素质比较低开窗对B狂骂：快给老子让开，B很生气，你妈逼的，老子就不让（死锁发生条件3：在未使用完资源前，不能被其他线程剥夺），于是两者相互僵持一个都走不了（死锁发生条件4：环路等待条件），而且导致整条道上的后续车辆也走不了。
活锁：马路中间有条小桥，只能容纳一辆车经过，桥两头开来两辆车A和B，A比较礼貌，示意B先过，B也比较礼貌，示意A先过，结果两人一直谦让谁也过不去。
关于”饥饿“的比喻： 在“首堵”北京的某一天，天气阴沉，空气中充斥着雾霾和地沟油的味道，某个苦逼的临时工交警正在处理塞车，有两条道A和B上都堵满了车辆，其中A道堵的时间最长，B相对相对堵的时间较短，这时，前面道路已疏通，交警按照最佳分配原则，示意B道上车辆先过，B道路上过了一辆又一辆，A道上排队时间最长的确没法通过，只能等B道上没有车辆通过的时候再等交警发指令让A道依次通过，这也就是ReentrantLock显示锁里提供的不公平锁机制（当然了，ReentrantLock也提供了公平锁的机制，由用户根据具体的使用场景而决定到底使用哪种锁策略），不公平锁能够提高吞吐量但不可避免的会造成某些线程的饥饿。
③spring在框架中主要干些什么？ beanFactory(工厂模式) 使用IOC控制反转，进行依赖注入 spring aop的事务管理 声明式的事务管理
④javaEE是什么？ 说实话我当时有点蒙圈，我平时还真没注意这货的具体概念，于是我就回答是java web的开发构架什么什么的 Java EE，Java平台企业版（Java Platform Enterprise Edition），是Sun公司为企业级应用推出的标准平台。Java平台共分为三个主要版本Java EE、Java SE和Java ME。（来自维基百科）
⑤spring 中的事务是如何实现的？一个事务下有A，B两个方法，另外有一个C（不是事务）里调用 A，B，A如果失败了B会怎样？ 我当时回答了因为原子性，就像银行系统取钱一样，会事务回滚，B不会执行，其实这个我也没怎么用过，也不知道回答得对不对，下面补充以下最后获得的资料： 事务管理对于企业应用而言至关重要。它保证了用户的每一次操作都是可靠的，即便出现了异常的访问情况，也不至于破坏后台数据的完整性。 编程式事务管理 Spring 的编程式事务管理概述
在 Spring 出现以前，编程式事务管理对基于 POJO 的应用来说是唯一选择。用过 Hibernate 的人都知道，我们需要在代码中显式调用beginTransaction()、commit()、rollback()等事务管理相关的方法，这就是编程式事务管理。通过 Spring 提供的事务管理 API，我们可以在代码中灵活控制事务的执行。在底层，Spring 仍然将事务操作委托给底层的持久化框架来执行。
声明式事务管理 Spring 的声明式事务管理概述
Spring 的声明式事务管理在底层是建立在 AOP 的基础之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。
声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明（或通过等价的基于标注的方式），便可以将事务规则应用到业务逻辑中。因为事务管理本身就是一个典型的横切逻辑，正是 AOP 的用武之地。Spring 开发团队也意识到了这一点，为声明式事务提供了简单而强大的支持。（此块引用自https://www.ibm.com/developerworks/cn/education/opensource/os-cn-spring-trans/）
声明式事务管理曾经是 EJB 引以为傲的一个亮点， Spring 让 POJO 在事务管理方面也拥有了和 EJB 一样的待遇，让开发人员在 EJB 容器之外也用上了强大的声明式事务管理功能，这主要得益于 Spring 依赖注入容器和 Spring AOP 的支持。 简单的说，编程式事务是需要在业务逻辑中掺杂事务管理的代码等（如事务申明，提交等），而声明式事务，开发比较简单，不需要通过编程的方式管理事务，不需要在业务逻辑代码加入事务管理的代码，只用在配置文件中配置做相关事务声明的规则定义即可（全文完）。
