面试

练习代码： 练习代码： 1 //这条语句说明这个Java文件在demo的包下 2 package demo1; 3 /** 4 * 5 * @author 王兴平 6 * 这个是第一个hello world 案例 7 * 这个注释是文本注释 8 * 注释内容是不会编译的，编译器会忽略其存在 9 * 10 */ 11 // 这是一个单行注释 现在用它描述个语句的功能 12 /* 13 * 这是多行注释 14 * 用它来描述内的工能的详细介绍 15 * 或者实现步骤 16 */ 17 /* 18 * 实现步骤： 19 * 1.定义一个类 class 20 * 2.编写程序执行的入口方法，main主方法 21 * 3.通过输出语句System.out.println()将信息”HelloWorld!”打印在控制台上 22 */ 23 24 //这条语句说明这个类的名字注意要和文件明相同 25 public class Helloworld { 26 //这是一个主方法程序执行的入口 27 public static void main(String[] args) { 28 //这是一条控制台输出语句 29 System.out.println("Hello World!"); 30 } 31 } 1 package demo2; 2 /** 3 * 4 * @author 王兴平 5

什么是增强for循环 增强for循环是一种简单模式的for循环，为了方便数组和集合的遍历而存在。 int [ ] arr = new int [ ] { 1 , 2 , 3 , 4 , 5 , 6 } ; for ( int a : arr ) { System . out . println ( a ) ; } ArrayList < Integer > list = new ArrayList ( ) ; list . add ( 1 ) ; list . add ( 2 ) ; list . add ( 3 ) ; list . add ( 4 ) ; list . add ( 5 ) ; list . add ( 6 ) ; for ( int i : list ) { System . out . println ( i ) ; } //加入Java开发交流君样：756584822一起吹水聊天 增强for循环的原理 对于集合的遍历，增强for循环其实内部是通过迭代器实现的，可以做一个简单的验证，我们知道在迭代器中，迭代的时候不允许修改，不然会抛出ConcurrentModificationException异常，那我们不妨在增强型for循环中也尝试去修改集合中的对象，看是否抛出同样的异常。 ArrayList < Integer > list = new

在读很多并发文章中，会提及各种各样锁如公平锁，乐观锁等等，这篇文章介绍各种锁的分类。介绍的内容如下： 公平锁/非公平锁 可重入锁 独享锁/共享锁 互斥锁/读写锁 乐观锁/悲观锁 分段锁 偏向锁/轻量级锁/重量级锁 自旋锁 上面是很多锁的名词，这些分类并不是全是指锁的状态，有的指锁的特性，有的指锁的设计，下面总结的内容是对每个锁的名词进行一定的解释。 公平锁/非公平锁 公平锁是指多个线程按照申请锁的顺序来获取锁。 非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。 对于Java ReentrantLock而言，通过构造函数指定该锁是否是公平锁，默认是非公平锁。非公平锁的优点在于吞吐量比公平锁大。 对于Synchronized而言，也是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁。 可重入锁 可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。说的有点抽象，下面会有一个代码的示例。 对于Java ReentrantLock而言, 他的名字就可以看出是一个可重入锁，其名字是Re entrant Lock重新进入锁。 对于Synchronized而言,也是一个可重入锁

Java 异常面试题 （13） 参考文章： （1）Java 异常面试题 （13） （2）https://www.cnblogs.com/ljangle/p/10681782.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4437974/blog/4928382

整洁架构、CQRS、六边形架构等微服务架构都旨在“高内聚低耦合”。那DDD分层架构又如何？ 1 DDD分层架构 1.1 分层架构的基本原则 每层只能与位于其下方的层发生耦合。 1.2 分层架构的分类 严格分层架构(Strict Layers Architecture) 某层只能与其直接下层耦合，即我的奴隶的奴隶，不是我的奴隶。 松散分层架构(Relaxed Layers Architecture) 允许任意上层与任意下层耦合。由于用户接口层和应用服务通常需要与基础设施打交道，许多系统都是该架构。 较低层有时也可与较高层耦合，但只限于采用观察者 (Observer)模式或者调停者(Mediator)模式场景。较低层 绝不能直接访问 较高层。例如，在使用调停者模式时，较高层可能实现了较低层的接口，然后将实现对象作为参数传递到较低层。当较低层调用该实现时， 它并不知道实现出自何处。 1.3 分层架构演进 1.3.1 传统四层架构 将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层逻辑的依赖，因为它们不属业务逻辑。将一个夏杂的系统分为不同的层，每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。 传统分层架构的 基础设施层 位于底层，持久化和消息机制便位于该层。这里的消息包含MQ消息、SMTP或文本消息(SMS)。可将基础设施层中所有组件看作应用程序的低层服务

时间是不可逆的，我们不可能经历之后，然后再返回来修正自己过去的行为，但是我们可以通过观察不同时间段的相同职业人的现状来修正自己。 最近一段时间，浪尖忙于招人面试，在面试别人的过程中收获了很多，我相信被我面试的人也会收获很多。 面试者的工作经验有十年以上的，有五六年，还有两三年的，每个年龄段都有自己的优点和缺点（这是句废话，每个人都是优缺点参半，实际上强调的是技术实力的优缺点），在这里，其实我想表达的事情是 通过不同年龄段的人在技术及经验方面的表现，可以映射到我们每一个人在不同年龄段的技术及经验的表现，通过多个人的历程来映射或者是分析我们自身在不同年龄段的状况。 对于十年左右工作经验的人 ，一般勤奋的人的资历、技术经验、项目管理经验及整个架构的言语表达都是非常赞的。但是，可能是父母，老婆，孩子等相关人、事耗去了很大的精力，在新技术的学习掌握能力上不是很好，当然了有实战的平台和心劲儿才是这块的关键。当然，这种人我们关注的应该是项目经验、架构能力、管理能力及表达能力，最好对新的技术框架有自己的认识，技术细节等我们不太关注，这个浪尖面试的比较少，原因是因为我们招的是干活的人而不是管干活的人。 对于五年左右工作经验的人 ，正当年，项目经验、技术实力、编程功底、架构能力都应该很赞，但是面试很多个都是什么都接触了，什么都用了，通过问问题和自我描述确实做过， 高考查分 但是架构设计一般般

这是第一次那个在osc上写博文，希望大家能多多支持。 首先谈谈昨天的面试，一个网易游戏，一个卓望公司，从招聘的要求来看，需要mysql高级（现在看来最起码有3年经验吧），oracle当然也是要充分的经验。现在回想毕竟还是抱了一些尝试的心态。本人工作4年，3年oracle开发经验，2年mysql dba经验。 网易游戏： 其实dba是个要求比较综合的职位，面试官也是来个一个开发的和一个专职dba。本人从2013年3月份开始接触mysql到现在，也有快2年的mysql经验了。从dba的角度来讲，没有百万、千万数量级的运维，那么经验知识有限的经验。以前也看过腾讯架构的演变，有句话还记得就是：数据量上来一个等级，以前没有的问题到现在都是问题。好了，先不废话。 网易游戏在广州的办公地方，看上去还不错。稍微的等待就2个面试官把我拉进了”小黑屋“。客气的来个几个问题，马上就开始聊mysql了，mysql现在是如此的收重视（后面那个面试也重点谈了mysql）。 1 mysql常用存储引擎？myisiam、innodb、memory。。如数家珍 2 mysql架构？master-salver、变种m-s、双mm等 3 mysql myisam与innodb的区别？。。。。这个劈啪啦就说了一大堆。 谈到mysiam时，问及用那种方式进行备份。我回答dump，立马被叼了一下。为什么不用copy不是更快吗

你是一台电脑，你的名字叫 A 经过 《你管这破玩意儿叫网络？》 这篇文章中的一番折腾，只要你知道另一位伙伴 B 的 IP 地址，且你们之间的网络是通的，无论多远，你都可以将一个数据包发送给你的伙伴 B 这就是物理层、数据链路层、网络层这三层所做的事情。 站在第四层的你，就可以不要脸地利用下三层所做的铺垫，随心所欲地发送数据，而不必担心找不到对方了。 虽然你此时还什么都没干，但你还是给自己这一层起了个响亮的名字，叫做 传输层 。 你本以为自己所在的第四层万事大吉，啥事没有，但很快问题就接踵而至。 问题来了 前三层协议只能把数据包从一个主机搬到另外一台主机，但是，到了目的地以后，数据包具体交给哪个 程序 （进程）呢？ 所以，你需要把通信的进程区分开来，于是就给每个进程分配一个数字编号，你给它起了一个响亮的名字： 端口号 。 然后你在要发送的数据包上，增加了传输层的头部， 源端口号 与 目标端口号 。 OK，这样你将原本主机到主机的通信，升级为了 进程和进程之间的通信 。 你没有意识到，你不知不觉实现了 UDP 协议 ！ （当然 UDP 协议中不光有源端口和目标端口，还有数据包长度和校验值，我们暂且略过） 就这样，你用 UDP 协议无忧无虑地同 B 进行着通信，一直没发生什么问题。 但很快，你发现事情变得非常复杂...... 丢包问题 由于网络的不可靠，数据包可能在半路丢失，而 A 和

面试官：“小陈，说一下你常用的SQL优化方式吧。” 陈小哈：“那很多啊，比如不要用SELECT *，查询效率低。巴拉巴拉...” 面试官：“为什么不要用SELECT * ？它在哪些情况下效率低呢？” 陈小哈：“SELECT * 它好像比写指定列名多一次全表查询吧，还多查了一些无用的字段。” 面试官：“嗯...” 陈小哈：“emmm~ 没了” 陈小哈：“....??（几个意思）” 面试官：“嗯...好，那你还有什么要问我的么？” 陈小哈：“我问你个锤子，把老子简历还我！” 无论在工作还是面试中，关于SQL中不要用“SELECT *”，都是大家听烂了的问题，虽说听烂了，但普遍理解还是在很浅的层面，并没有多少人去追根究底，探究其原理。 废话不多说，本文带你深入了解一下"SELECT * "效率低的原因及场景。 本文很干！请自备茶水，没时间看记得先收藏 -- 来自一位被技术经理毒打多年的程序员的忠告 一、效率低的原因 先看一下最新《阿里java开发手册（泰山版）》中 MySQL 部分描述： 4 - 1. 【强制】 在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。 说明： 增加查询分析器解析成本。 增减字段容易与 resultMap 配置不一致。 无用字段增加网络 消耗，尤其是 text 类型的字段。 开发手册中比较概括的提到了几点原因，让我们深入一些看看： 1.

（面试）大型网站应用之海量数据、高并发解决方案 参考文章： （1）（面试）大型网站应用之海量数据、高并发解决方案 （2）https://www.cnblogs.com/zhuzhen/p/9340941.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4438370/blog/4925214