目录
前言
面试对于职场的我们来说必不可少，有道是：工欲善其事，必先利其器，这次我想分享一下我的面试心旅！
本文会大量引用，在这里感谢各位作者的辛苦奉献！好了，话不多说，开整~
面试题篇
面向Java初级，毕竟本人还是刚毕业的职场小白呢~大佬见笑
百度面试题
- Spring的AOP实现原理
- 实现多态的方式
- HashMap底层原理
新浪面试题
- sleep和wait的区别？怎么唤醒？
- servlet是单例的么？为什么多个用户访问没有问题？servlet可以实现多例？
- new ArrayList 和 Arrays.asList有什么区别？
- hashMap底层原理
浪潮面试题
- 索引失效条件？怎么查询当前语句有索引？
- havingby、on、where有何不同？
- io流相关操作
- java线程池的创建？execute和submit的区别？
- 基于http的三次握手第二次已经建立连接了，为何还要第三次握手？
- 集合框架
- 八大排序算法
凤凰网面试题
- 海量日志数据，10g左右，怎么讲重复的日志删除？
我回答： distinct
追问：distinct的删除原理？
select id ，distinct（name）from user 这样写合法么？id是顺序遍历么？
3. MVC架构，Service扮演什么样的角色？
Java经典面试题目
这里给的Java面试题，我称之为经典题目，即市面上八成的公司都会问到这些问题的。我希望看到我这篇总结，您就可以一劳永逸了~！
Java基础
异常
反射
计算机网络
Spring
linux基础
Mybatis
WebService
集合框架
Mysql数据库
三大范式
第一范式(1NF)
(必须有主键，列不可分)
数据库表中的任何字段都是单一属性的，不可再分
create table aa(id int,NameAge varchar(100))
insert aa values(1,’'无限-女 ‘’)
没有达到第一范式
create table aa(id int,name varcahr(10),age char(2))
insert aa values(1,’‘无限’’,’'女 ‘’)
达到第一范式
第二范式(2NF)
数据库表中非关键字段对任一候选关键字段的 都 不存在部分函数依赖
(当一个表是复合主键时，非主键的字段不依赖于部分主键(即必须依赖于全部的主键字段))
create table sci(
sno int(32),cno int(32),grade int(32),credit int(32),
primary key sno,cno
)
课程(cno)1—1学分(credit)
学生(sno)n—n课程(cno)
学生+课程—>分数(grade)
sci
sno cno grade credit
1 1 60 80
2 1 90 80
3 1 70 80
. . . .
. . . .
. . . .
如此以来，学分被大量重复存储，数据冗余
如要某课程学分，则要大量重复操作
如要加新课程，由于sno和cno共同做为主键，则在加入新课程时，必须有人选该课
如某学生某课程结业，则该学生其它课程信息也同时被删除了
总之
这种设计不太好吧，非关键字属性credit仅函数依赖于cno，也就是credit部分依赖组合关键字（sno,cno）而不是完全依赖
解决
分成两个关系模式 sc1（sno,cno,grade），c2（cno,credit）。新关系包括两个关系模式，它们之间通过sc1中的外关键字cno相联系，需要时再进行自然联接，恢复了原来的关系
第三范式(3NF)
关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递依赖
例----S1（SNO，SNAME，DNO， DNAME， LOCATION)
学号 姓名 所在系 系名称 系地址
关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。
原因:关系中存在传递依赖造成的。即SNO 1->1 DNO。 而DNO 1->n SNO却不存在， 而DNO -> LOCATION存在, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。
解决目地：每个关系模式中不能留有传递依赖。
解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系
鲍依斯-科得范式（BCNF）
在3NF的基础上，库表中任何字段对任一候选关键字段的传递函数依赖都不存在
仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且管理员1—1仓库；仓库1—n物品。这个数据库表中存在如下决定关系：
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况，所以其不符合BCNF范式
解决:
把仓库管理关系表分解为二个关系表：
仓库管理：StorehouseManage(仓库ID, 管理员ID)
仓库：Storehouse(仓库ID, 存储物品ID, 数量)
Mysql性能优化
后续我会统一在高级篇继续深入讲解，这里说一些入门技巧
SQL语句的优化
查询时，能不要就不用，尽量写全字段名。
大部分情况连接效率远大于子查询。
多表连接时，尽量小表驱动大表，即小表 join 大表
在千万级分页时使用limit
对于经常使用的查询，可以开启缓存（redis），对于每天查log表的功能比如说排行榜这种，使用redis，es查询
使用 IP 而不是域名做数据库路径。避免 DNS 解析问题
表的优化
表的字段尽可能用NOT NULL
字段长度固定的表查询会更快
把数据库的大表按时间或一些标志分成小表
将表分区
关键字Explain
转：Mysql优化必备技能之Explain的使用以及Sql优化过程
JVM
多线程
算法经典题目
约瑟夫环问题
常用的排序算法
冒泡排序
选择排序
插入排序
希尔排序
归并排序
快速排序
堆排序
计数排序
读程序题
数据结构与算法
心路历程
态度
- 多闻阙疑，慎言其余；多见阙殆，慎行其余
- 独立思考
- 三人行必有我师焉
- 千里之行，始于足下
学习
- 启发式学习
它能帮我带来什么？spring的优缺点是什么？为什么用spring呢？
- 对比式学习
- 逆向式学习
- 无功利性学习
实践
- 学习优秀开源项目
- jdk、 spring、log4j、guava、velocity
- Apache Commons
- Apache Tomcat
- 仿照名家写法
- 多方位实现需求
- 深度思考
Tips
- 放弃完美主义
- 唾面自干的胸襟
- 包容他人的气度
- 低调做人
- 坚持不懈
