Java面试总结（二）

前几天去了几家公司面试，果真，基本所有倒在二面上，无语啊。。。不过幸亏，到最后拿到了环球易购的offer，打算就这么好好呆着了，学习学习，努力努力，下面讲讲这几天的面试吧。
　　先是恒大，一个组长面试，答的很通常吧，有些问题是确实不知道题意，如何设计一个多线程，用来表示一个红绿灯和车流的关系；还有人走迷宫的时候，如何用一个设计模式表示人的多样性和路的多样性；还有就是如何大批量向数据库插入数据，这个以前没关注过，没答出来，有点遗憾。还有就是薪资问题，来以前我觉得恒大，这么牛逼的公司，要不要提升一下薪资要求，不过为了稳妥仍是继续9-10k，面试官说刚毕业的，这边只能给到8k左右啊，，，，就这样，挂了。
　　达飞金控一面问的问题真的太基础，基础到有点吓人，差很少也是那种set、list、map区别，抽象和接口什么的，答得通常吧。因为面试官在开会，开到了12点多，而后继续面试，同时还有另外一个面试的在等，二面也聊得还算是蛮顺畅，问了若是不当心发送了两个重复的请求，因为不一样机房，数据同步须要时间，那么如何解决这个请求；还有就是在一段文字中找出出现次数最多的字谜，整体上来的还算是通常偏上吧，答得也七七八八，而后就1点了，还有另一我的在等面试，最后说等消息，到如今也没消息，又挂了。。。。蛇口那边的环境确实不错，面完下楼，好多外国人。还有就是达飞准备招人作风控、电商方面的业务，有须要的能够投一下。
　　联想的有点，，，对着一张纸的题直接说出答案，这个面试官说答的还不错，而后是手写sql和上机笔试，sql没写对（考察分页，group by，having），其实不难的，只是平时不注意，上机的题也没全作出来（考察Java日期类的使用，有点古老），不过还好有个本身的网站二面仍是过了，三面，额，可能作得东西跟本身想的不同，当我说我想作分布式、高并发、高可用的东西以后，而后还问了部门manager并发量有多大，他说主要是给内部使用的，因此并发量不打，而后说等消息吧，就这么挂了，听说联想2020年在后海会落成一栋楼，感受屌屌的，惋惜了。。。。
永远挂在二面的我啊
　　深圳想去的公司而且招人的，基本投完了，而后这么多都是倒在了二面，有点不甘心吧。在boss上偶然看到环球易购在招人，并且一直是本身求之不得的电商行业，就在boss上找环球易购的那些技术负责人，一个一个问，还好有位大佬理我，虽然不合适，但帮忙推到了另外一个组，而后等HR电话，一直没答来，因此只能一直贯彻本身的方针：成功的三要素是，一坚持，二不要脸，三坚持不要脸，一直请问那位技术大佬，虽然特别很差意思。咱们常常说，千里马常有而伯乐不常有，那么一只不要脸的普通马就只能本身争取了23333。
　　周一去了环球易购，面试官挺直接的，感受好像大概知道我实力如何什么的，直接问难度稍微大一点点的问题，有点慌，并且回答的也不是太好，双亲委派还记反了（尴尬），而后是部门经理，这个我回答的更惨，惨不忍睹，问了tomcat如何解析一个请求，意思是tomcat源码看过没，，，，真的超级慌，当初看了一会源码就没坚持下去直接放弃了。不过还好能HR面了（终于有家公司是HR面了），中间件毕竟是我特别想整的东西。周三接到了offer，开心的一晚睡不着（加上没工做做息时间混乱），致使今天体检血压一直高，，，，如今真是超级累。
　　这年头找工做真的很累，最好不要像我同样裸辞，找不到工做内心真的很不舒服的，特别容易心态爆炸，有时候以为本身表现的还不错，但就是没过，很离谱的那种，毕竟面试，运气缘分什么的占比更重。我是由于在上家公司加班太严重，并且任务太忙，根本没时间面试和学习因此裸辞的。
　　下面是本身印象深入的题吧，有面试的能够参考参考，答案不必定准确，由于我本身也是半斤八两，也欢迎你们帮忙提醒一下。

1.MQ事务，若是消费者消费了，如何回滚

　　分布式事务，是我计划下下一阶段要看的东西（下一个是分布式锁），没想到这么快就被问到了，最初看的不过也就CAP、BASE、2PC、3PC这些，MQ事务真的不多接触。即便没学过，那就按本身的理解来吧。假设有三个事务：A、B、C。
（1）若是三个事务以前不须要彼此的依赖，能够执行完A的时候向消息队列发送一个prepareA，同理，B、C也同样，若是三个事务在本地都执行成功了，那么发送一次success，而后事务prepareA、prepareB、prepareC开始执行，若是有一个失败，则直接回滚全部。
（2）若是事务B须要依赖A的结果、C须要依赖B的结果，那么A执行完后再执行B，B执行完再执行C，到最后，其中若是有一个失败，则回滚重试。
　　这一块是真没接触过，即便百度了，感受也有点抽象，仍是先把ZooKeeper的分布式锁看完再整分布式事务的东西吧。百度的时候看到了一个比较相似的想法，说的比我好，能够看看。

参考：
分布式事务之最终一致的Mq实现
聊聊分布式事务，再说说解决方案

2.主线程如何捕获子线程的异常

　　这道题不是很理解他的意思，try catch不就好了？他说不是这个意思，我说用线程池的话能够用callable异步返回异常结果，他说这个不算吧，一脸懵逼的状态，过后百度了下发现考点是UncaughtExceptionHandler。。。大概意思就是把线程交给线程组，而后再线程组里重写异常捕获方法，便可在主线程捕获子线程的异常了，例子以下：

public class ThreadExcep extends ThreadGroup {
    private ThreadExcep() {
        super("线程组的名字");
    }
    public void uncaughtException(Thread thread, Throwable exception) {
        System.out.println(thread.getId());
        exception.printStackTrace();//example,   print   stack   trace
    }
    public static void main(String[] args) {
        ThreadExcep excep = new ThreadExcep();
        Thread thread = new Thread(excep, () -> {
            throw new NullPointerException("空指针异常");
        });
        thread.start();
    }
}

结果以下：

11
java.lang.NullPointerException: 空指针一场
    at com.study.exception.ThreadExcep.lambda$main$0(ThreadExcep.java:26)
    at java.lang.Thread.run(Thread.java:748)

　　而若是去掉exception.printStackTrace()，程序是不打印报错信息的。缘由能够总结以下：
（1）若是在主线程中建立一个子线程，默认状况下这两个线程同属于一个线程组，若是子线程发生异常，主线程能够直接使用try catch捕获的到。
（2）一样是在主线程中建立一个子线程，若是声明了这个子线程是另外一个线程组的，即调用了new Thread(ThreadGroup group, Runnable target)，则主线程中是没法直接捕获到子线程的发生的异常的，不过能够经过在声明一个线程组重写uncaughtException，而后把子线程放进去。
无论怎么说，在主线程中捕获子线程的异常通常是不推荐的，线程设计的理念：“线程的问题应该线程本身自己来解决，而不要委托到外部。”
参考：
【Java 多线程】Java中主线程如何捕获子线程抛出的异常

3.大批量插入数据库如何优化

　　大批量，以前都没怎么注意过，这个问题确实不会，网上参考了下别人的，大致上是这个意思：合并数据+事务的方法在较小数据量时，性能提升是很明显的，数据量较大时（1千万以上），性能会急剧降低，这是因为此时数据量超过了innodb_buffer的容量，每次定位索引涉及较多的磁盘读写操做，性能降低较快。而使用合并数据+事务+有序数据的方式在数据量达到千万级以上表现依旧是良好，在数据量较大时，有序数据索引定位较为方便，不须要频繁对磁盘进行读写操做，因此能够维持较高的性能。

参考：
数据库大批量SQL插入性能优化

4.Spring Bean的生命周期

　　Spring的源码确实要找个时间好好看看了，下面的是参考自《Spring实战的》内容。

主要流程以下：
(1).Spring对Bean进行实例化（至关于程序中的new Xx()）
(2).Spring将值和Bean的引用注入进Bean对应的属性中
(3).若是Bean实现了BeanNameAware接口，Spring将Bean的ID传递给setBeanName()方法（实现BeanNameAware清主要是为了经过Bean的引用来得到Bean的ID，通常业务中是不多有用到Bean的ID的）
(4).若是Bean实现了BeanFactoryAware接口，Spring将调用setBeanDactory(BeanFactory bf)方法并把BeanFactory容器实例做为参数传入。（实现BeanFactoryAware 主要目的是为了获取Spring容器，如Bean经过Spring容器发布事件等）
(5).若是Bean实现了ApplicationContextAwaer接口，Spring容器将调用setApplicationContext(ApplicationContext ctx)方法，把y应用上下文做为参数传入.(做用与BeanFactory相似都是为了获取Spring容器，不一样的是Spring容器在调用setApplicationContext方法时会把它本身做为setApplicationContext 的参数传入，而Spring容器在调用setBeanDactory前须要程序员本身指定（注入）setBeanDactory里的参数BeanFactory )
(6).若是Bean实现了BeanPostProcess接口，Spring将调用它们的postProcessBeforeInitialization（预初始化）方法（做用是在Bean实例建立成功后对进行加强处理，如对Bean进行修改，增长某个功能）
(7).若是Bean实现了InitializingBean接口，Spring将调用它们的afterPropertiesSet方法，做用与在配置文件中对Bean使用init-method声明初始化的做用同样，都是在Bean的所有属性设置成功后执行的初始化方法。
(8).若是Bean实现了BeanPostProcess接口，Spring将调用它们的postProcessAfterInitialization（后初始化）方法（做用与6的同样，只不过6是在Bean初始化前执行的，而这个是在Bean初始化后执行的，时机不一样 )
(9).通过以上的工做后，Bean将一直驻留在应用上下文中给应用使用，直到应用上下文被销毁
(10).若是Bean实现了DispostbleBean接口，Spring将调用它的destory方法，做用与在配置文件中对Bean使用destory-method属性的做用同样，都是在Bean实例销毁前执行的方法。

参考：
1.《Spring实战》
2.Spring中Bean的生命周期是怎样的？

5.Tomcat是如何解析一个请求的

万万没想到啊，本身曾经研究过一点点tomcat的源码，如今却忘光了，留张图先吧，以后写源码分析的系列。

6.代理模式（Spring）

这题以后看Spring源码的时候再总结了。

7.Java类里的静态变量在JVM中哪一个区

JDK8以前，静态成员变量确实存放在方法区；但JDK8以后就取消了“永久代”，取而代之的是“元空间”，永久代中的数据也进行了迁移，静态成员变量迁移到了堆中（方法区是JVM的规范，永久代是方法区的具体实现）。

8.ORM的好处，为何使用ORM

惊不惊喜，意不意外，大部分人都在用ORM，可是却不多关注为何吧。Object-Relationl Mapping，它的做用是在关系型数据库和对象之间做一个映射，这样，咱们在具体的操做数据库的时候，就不须要再去和复杂的SQL语句打交道，只要像平时操做对象同样操做它就能够了 。
优势
（1）方便的使用面向对象来进行额外的操做，语句清晰
（2）防注入
（3）方便动态构造语句，对于不一样的表的相同操做采用多态实现更优雅
（4）必定程度方便重构数据层『好比改表名，字段名等』
缺点
（1）不太容易处理复杂查询语句
（2）性能较直接用SQL差，毕竟有个转化过程更。

总结

这些日子的面试过程，有基础的，有广度的，也暴露了本身不少不少缺点，2018还得继续努力，最怕的是比你厉害的人还比你努力吧，不过怎么说，但愿各位在求职稳住心态，猥琐发育，前程似锦。