关于java研发工程师面试相关的部分参考

www.allocmem.com · · 507 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

今天受邀去参加了某个公司面试的第二轮复试,今天复试的是公司的一个项目主管,感觉比之前面试的更懂技术一些,还问了一些比较刁钻的问题,在这里记录一些自己的不足和自己觉得比较有价值的东西,作为自己的部分参考。

①关于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 的支持。 简单的说,编程式事务是需要在业务逻辑中掺杂事务管理的代码等(如事务申明,提交等),而声明式事务,开发比较简单,不需要通过编程的方式管理事务,不需要在业务逻辑代码加入事务管理的代码,只用在配置文件中配置做相关事务声明的规则定义即可(全文完)。

本文来自:www.allocmem.com

感谢作者:www.allocmem.com

查看原文:关于java研发工程师面试相关的部分参考

507 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传