java秋招面经

B树：https://www.jianshu.com/p/7dedb7ebe033

B+树：https://blog.csdn.net/guoziqing506/article/details/64122287

https://blog.csdn.net/lkforce/article/details/79077270

 

MySQL索引原理：https://blog.csdn.net/suifeng3051/article/details/52669644/

度的计算：dmax=floor(pagesize/(keysize+datasize+pointsize))//floor表示向下取整

MyISAM索引实现：非聚集索引

特点：

1、主索引和辅助索引相同，只是主索引要求key是唯一的，而辅助索引的key可以重复。

2、叶节点的data域存放的是数据记录的地址

InnoDB：聚集索引

1、重大区别是InnoDB的数据文件本身就是索引文件，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。

2、所以InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。

3、第二个与MyISAM索引的不同是InnoDB的辅助索引data域存储相应记录主键的值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。

总结：这里以英文字符的ASCII码作为比较准则。聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。

了解不同存储引擎的索引实现方式对于正确使用和优化索引都非常有帮助，例如知道了InnoDB的索引实现后，就很容易明白为什么不建议使用过长的字段作为主键，因为所有辅助索引都引用主索引，过长的主索引会令辅助索引变得过大。再例如，用非单调的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一颗B+Tree，非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。

 

索引使用策略及优化

MySQL的优化主要分为结构优化（Scheme optimization）和查询优化（Query optimization）。本章讨论的高性能索引策略主要属于结构优化范畴。本章的内容完全基于上文的理论基础，实际上一旦理解了索引背后的机制，那么选择高性能的策略就变成了纯粹的推理，并且可以理解这些策略背后的逻辑。

6.1 联合索引及最左前缀原理

联合索引（复合索引）

首先介绍一下联合索引。联合索引其实很简单，相对于一般索引只有一个字段，联合索引可以为多个字段创建一个索引。它的原理也很简单，比如，我们在（a,b,c）字段上创建一个联合索引，则索引记录会首先按照A字段排序，然后再按照B字段排序然后再是C字段，因此，联合索引的特点就是：

• 第一个字段一定是有序的

• 当第一个字段值相等的时候，第二个字段又是有序的，比如下表中当A=2时所有B的值是有序排列的，依次类推，当同一个B值得所有C字段是有序排列的

  | A | B | C | 
  | 1 | 2 | 3 | 
  | 1 | 4 | 2 | 
  | 1 | 1 | 4 | 
  | 2 | 3 | 5 | 
  | 2 | 4 | 4 | 
  | 2 | 4 | 6 | 
  | 2 | 5 | 5 |

其实联合索引的查找就跟查字典是一样的，先根据第一个字母查，然后再根据第二个字母查，或者只根据第一个字母查，但是不能跳过第一个字母从第二个字母开始查。这就是所谓的最左前缀原理。

6.2 索引优化策略

• 最左前缀匹配原则，上面讲到了
• 主键外检一定要建索引
• 对 where,on,group by,order by 中出现的列使用索引
• 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0
• 对较小的数据列使用索引,这样会使索引文件更小,同时内存中也可以装载更多的索引键
• 索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
• 为较长的字符串使用前缀索引
• 尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可
• 不要过多创建索引, 权衡索引个数与DML之间关系，DML也就是插入、删除数据操作。这里需要权衡一个问题，建立索引的目的是为了提高查询效率的，但建立的索引过多，会影响插入、删除数据的速度，因为我们修改的表数据，索引也需要进行调整重建
• 对于like查询，”%”不要放在前面。 
  SELECT * FROMhoudunwangWHEREunameLIKE'后盾%' -- 走索引 
SELECT * FROMhoudunwangWHEREunameLIKE "%后盾%" -- 不走索引
• 查询where条件数据类型不匹配也无法使用索引 
  字符串与数字比较不使用索引; 
  CREATE TABLEa(achar(10)); 
EXPLAIN SELECT * FROMaWHEREa="1" – 走索引 
  EXPLAIN SELECT * FROM a WHERE a=1 – 不走索引 
  正则表达式不使用索引,这应该很好理解,所以为什么在SQL中很难看到regexp关键字的原因

七、为什么说B+树比B树更适合数据库索引？

1、 B+树的磁盘读写代价更低：B+树的内部节点并没有指向关键字具体信息的指针，因此其内部节点相对B树更小，如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的需要查找的关键字也就越多，相对IO读写次数就降低了。

2、B+树的查询效率更加稳定：由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

3、由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树（存储具体节点）因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树（存储范围）更加适合在区间查询的情况，所以通常B+树用于数据库索引。

PS：我在知乎上看到有人是这样说的,我感觉说的也挺有道理的：

他们认为数据库索引采用B+树的主要原因是：B树在提高了IO性能的同时并没有解决元素遍历的我效率低下的问题，正是为了解决这个问题，B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作或者说效率太低。

 

 

今天看了几篇文章，自己总结一下。

数据库使用B+树肯定是为了提升查找效率。

但是具体如何提升查找效率呢？

查找数据，最简单的方式是顺序查找。但是对于几十万上百万，甚至上亿的数据库查询就很慢了。

所以要对查找的方式进行优化，熟悉的二分查找，二叉树可以把速度提升到O(log(n,2))，查询的瓶颈在于树的深度，最坏的情况要查找到二叉树的最深层，由于，每查找深一层，就要访问更深一层的索引文件。在多达数G的索引文件中，这将是很大的开销。所以，尽量把数据结构设计的更为‘矮胖’一点就可以减少访问的层数。在众多的解决方案中，B-/B+树很好的适合。B-树定义具体可以查阅，简而言之就是中间节点可以多余两个子节点，而且中间的元素可以是一个域。相比B-树，B+树的父节点也必须存在于子节点中，是其中最大或者最小元素，B+树的节点只存储索引key值，具体信息的地址存在于叶子节点的地址中。这就使以页为单位的索引中可以存放更多的节点。减少更多的I/O支出。因此，B+树成为了数据库比较优秀的数据结构，MySQL中MyIsAM和InnoDB都是采用的B+树结构。不同的是前者是非聚集索引，后者主键是聚集索引，所谓聚集索引是物理地址连续存放的索引，在取区间的时候，查找速度非常快，但同样的，插入的速度也会受到影响而降低。聚集索引的物理位置使用链表来进行存储。

二、HashMap:

https://segmentfault.com/a/1190000012926722

 

三、徐刘根的博客

https://blog.csdn.net/xlgen157387

多线程：

ThreadLocal：

java面试：

 

四、骆昊的博客

Java面试题全集（上）:

https://blog.csdn.net/jackfrued/article/details/44921941

1、面向对象的特征有哪些方面？

- 抽象：抽象是将一类对象的共同特征总结出来构造类的过程，包括数据抽象和行为抽象两方面。抽象只关注对象有哪些属性和行为，并不关注这些行为的细节是什么。

- 多态性：多态性是指允许不同子类型的对象对同一消息作出不同的响应。简单的说就是用同样的对象引用调用同样的方法但是做了不同的事情。方法重载（overload）实现的是编译时的多态性（也称为前绑定），而方法重写（override）实现的是运行时的多态性（也称为后绑定）。运行时的多态是面向对象最精髓的东西，要实现多态需要做两件事：1). 方法重写（子类继承父类并重写父类中已有的或抽象的方法）；2). 对象造型（用父类型引用引用子类型对象，这样同样的引用调用同样的方法就会根据子类对象的不同而表现出不同的行为）

五、 serlvet的理解

1：serlvet是单实例的。

解释：在web容器中，比如tomcat(命名为A)中，一个web(命名B)应用中，有一个UserServlet，这个UserServlet是一个单例，也就是说，在这个A的B中有且仅有一个UserServlet。

2：UserSerlvet接受UserId,返回UserName，多个用户访问的时候，是多个线程在运行，你说的前一个用户，后一个用户，对应多个线程。用户=线程，暂时这么理解吧。

比如你说的例子：

id=1 name=jack

id=2 name=tom

线程1访问了UserServet，接受到UserId为1，并没有返回UserName，线程1未结束

线程2访问了UserServet，接受到UserId为2，查询结果，返回UserName=Tom，线程2结束

线程1查询结果，返回什么？返回jack

因为线程1和线程2是两个独立的线程，接受到Userid为线程内部方法的局部变量，根据id查询出来的UserName，有效范围也仅在每个线程的查询方法内有效！(前提条件是UserName是方法的局部变量，不要把UserName声明成实例变量！！)

线程1不能获得线程2的UserId=2，也不能获得线程2的UserName=Tom。

因为UserId，UserName的声明，都在Servlet的方法内部，(如果你放到方法外面，就会有问题)，

每个线程都会有自己的UserId，UserName，存在VM Stack中，方法结束，线程结束，这些UserId，UserName，失去与GCRoot的联系，会等待被GC回收，最终被清除。

综上：

多个用户访问同一个Servlet的时候，会不会出现冲突，取决于访问的Servlet的方法里面是否有Servlet的实例变量，如果有，多个用户共享这个实例变量，如果没有则互不影响，各回各家，各找各妈。

如果没看懂或不明白：在Servlet中尽量不要使用自定义的实例变量！

 

操作系统：

https://blog.csdn.net/houzuoxin/article/details/38957969

 

什么是并发编程？

什么是异步编程？

 

 

Spring 

https://www.cnblogs.com/ITtangtang/p/3978349.html

https://blog.csdn.net/u012868901/article/details/79479300