Java面试题zs

第一层：service层，接口层，给服务提供者和消费者来实现的
第二层：config层，配置层，主要是对dubbo进行各种配置的
第三层：proxy层，服务代理层，透明生成客户端的stub和服务端的skeleton
第四层：registry层，服务注册层，负责服务的注册与发现
第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
第六层：monitor层，监控层，对rpc接口的调用次数和调用时间进行监控
第七层：protocol层，远程调用层，封装rpc调用
第八层：exchange层，信息交换层，封装请求响应模式，同步转异步
第九层：transport层，网络传输层，抽象mina和netty为统一接口
第十层：serialize层，数据序列化层

1.provider向注册中心注册

2.consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务

3.consumer调用provider

4.consumer和provider都异步的通知监控中心

1.面向接口的远程方法调用

2.智能容错和负载均衡

3.服务自动注册与发现

tail -f  -n 最后几行

1.tail -f可以查询文件实时变化情况

2. top命令用于实时显示 process 的动态

电商项目

2前端5后端3测试

2.首页商品分类

3.商品详情页

4.单点登录

5.购物车

6.订单

1.clean

2.default

3.site

1.分布式执行效率快

2.容灾能力更强

3.容纳的数据量更大

针对集合迭代器的增强，能够更高效的完成聚合，过滤，或者大批量的操作，流与lambda表达式结合，编码效率大大提高
类型转换非常方便，比如我想把一个List转换成Map，不用流的话我需要写很多代码，流只需要一行代码就能搞定

1.HashMap是基于哈希表对Map接口的实现，HashMap]与HashTable相比允许使用null值和null键（源码的注释），并且是线程不安全的

2.HashMap初始化是在首次调用put()方法时，默认创建长度为16的数组，负载因子0.75

3.jdk7底层结构只有：数组+链表。jdk8底层：数组+链表+红黑树

4.插入元素时，先调用hash()方法，获取hash值：元素角标(n-1) & hash（n是集合长度）
   根据hash值来决定插入的值存放在哪个位置hash = (key==null) ? 0 : (h = key.hashCode()) ^ (h>>>16)

5.存取无序

6.HashMap继承AbstractMap实现Map；设计上的一个小错误

7.初始容量必须为2的n次方

8.如果初始容量不给2的n次方：会返回一个大于给定值的最小的2的n次方的一个值

9.当数组的某一个索引位置上的元素以链表形式存在的数据个数 > 8 且当前数组长度 > 64时，反树化值为6

10.put方法

补充：LinkedHashMap:   HashMap保证成对元素唯一，并且查询速度很快，可是成对元素存放进去是没有顺序的，那么我们要保证有序，还要速度快怎么办呢？
在HashMap下面有一个子类LinkedHashMap，它是链表和哈希表组合的一个数据存储结构。

1.list有序可重复，set无序不可重复，map是键值对，map中的key相当于一个set

2.list,set继承Collection，map单独的一个顶层接口

3.set查询慢，增删快，增加和删除不会引起元素位置改变，list和数组类似，可以动态增长，查找效率高。

Map和Set关系补充 ：Set的内部实现其实是一个Map。即HashSet的内部实现是一个HashMap，TreeSet的内部实现是一个TreeMap，LinkedHashSet的内部实现是一个LinkedHashMap。

1.通过反射可以知道任意一个类的所有属性和方法

2.通过反射可以调用任意一个对象的所有方法和属性

3.这是一种动态获取信息和动态调用对象的方法的功能

4.获取类对象

1.lambda表达式

2.Stream流

3.函数式接口

4.永久代-->元空间

1.Array是动态数组的数据结构，Link是链表的数据结构

2.查找Array效率高（get，set）、增删（add，remove）Link效率高

3.Array需要手动设置固定大小的容量，Link动态随数据量的变化而变化

1.ArrayList

2.HashSet

3.HashMap

1.stringBuilder速度快，线程不安全

2.stringBuffer速度慢，线程安全

1.单例模式

2.工厂模式

3.装饰模式

4.代理模式

1.深拷贝和浅拷贝就是指对象的拷贝，一个对象存在两种类型的属性，一种是基本数据类型，一种是实例对象的引用

2.浅拷贝：只会拷贝基本数据类型的值，以及实例对象的引用，并不会复制一份引用地址所指向的对象，内部类属性指向的是同一个对象

3.深拷贝：既拷贝基本数据类型的值，也会针对实例对象的引用地址所指向的对象进行复制，内部的类执行指向的不是同一个对象

1.开源免费，同时也支持收费版

2.可以跨平台

3.用起来也特别的方便

1.SQL优化一般在哪些字段上面加索引

1,遇到子查询转为连表查询

2.排序、分组优化

1.READ_UNCOMMITTED：读未提交

2.READ_COMMITTED：读已提交

3.REPEATABLE_READ：可重复读 （默认）

4.SERLALIZABLE：串行化

1.where不能用聚合函数、having中可以使用聚合函数（SUM, COUNT, MAX, AVG）

2.where是一个约束声明，用来约束来自数据库的数据，having是一个过滤声明

3.where是在结果返回之前起作用的，having是在查询返回结果集以后，对查询结果进行的过滤

1.from

2.join

3.on

4.where

5.group by

6.avg,sum等聚合函数

7.having

8.select

9.distinct

10.order by

11.limit

聚簇索引:将数据存储与索引放到了一块、并且是按照一定的顺序组织的，找到索引也就找到了数据，

非聚簇索引叶子节点不存储数据、存储的是数据行地址，也就是说根据索引查找到数据行的位置再取磁盘查找数据，这个就有点类似一本书的目录，

2.非主键索引都是非聚簇索引

3.MyISAM引擎不支持聚簇索引，只有主键索引

1、查询通过聚簇索引可以直接获取数据，相比非聚簇索引需要第二次查询(非覆盖索引的情况下)效率要高

2、聚簇索引对于范围查询的效率很高，因为其数据是按照大小排列的

3、聚簇索引适合用在排序的场合，非聚簇索引不适合

system->const->eq_ref->ref->range->index->all

innodb和myisam的区别

1、设计良好的数据库结构， 允许部分数据冗余， 尽量避免 join 查询， 提高效率。 

2、选择合适的表字段数据类型和存储引擎， 适当的添加索引。 

3、MySQL 库主从读写分离。 

4、找规律分表， 减少单表中的数据量提高查询速度。

5、书写高效率的 SQL。不要使用 SELECT * FROM TABEL，用什么字段就查什么字段

6.show profiles查看最近的SQL执行时间

1.主键、where后面字段、外键或者关联字段、排序、分组字段；优先组合索引

1.模糊查询LIKE以%开头

2.数据类型错误（类型转换）

3.函数sum...

4.索引列的null（空）

5.索引列进行四则运算

6.最佳左前缀（复合索引不按索引列最左开始查找）

7.全表查找预计比索引更快

不会影响性能

复杂复杂的sql语句，提高复用性，只保存sql逻辑，不保存任何查询结果

针对失效的原因对sql进行优化

1.日志分析工具mysqldslow

1.原子性

2.一致性

3.隔离性

4.持久性

1.脏读

2.不可重复度

3.幻读

1.垂直拆分

2.水平拆分

1.构造器循环依赖

2.feild属性注入循环依赖

3.三级缓存

4.debug查看

5.总结

6.核心方法

7.其他衍生问题

1.REQUIRED：支持当前事务，如果事务不存在，就新建事务

2.SUPPORTS：支持当前事务，如果事务不存在，就以非事务方式运行

3.MANDATORY：支持当前事务，如果事务不存在，就抛出异常

4.REQUIRES_NEW：挂起当前事务，以新事务运行

5.NOT_SUPPORTS：挂起当前事务，以非事务方式运行

6.NEVER：以非事务运行，如果事务存在，就抛出异常

7.NESTED：嵌套事务，基于jdbc3.0提高的SavePoint技术实现

问题：@Component这个注解把该类注入到spring容器中了，但是在拦截器之中不生效，再在Utils使用到dao，我们就不能直接注入了

解决方案：使用ApplicationContextAware解决问题。而ApplicationContextAware实现了这个接口的bean，
当spring容器初始化的时候，会自动的将ApplicationContext注入进来

1.请求到达DispatcherServlet，doDispatch()方法

2.DispatchServlet收到请求调用HandlerMapping处理器映射器

3.处理器映射器找到具体的处理器，生成处理器对象及处理器拦截器(集合)一并返回给DispatchServlet

4.DispatchServlet调用HandlerAdapter处理器适配器

5.HandlerAdapter经过适配调用具体的处理器（Controller，也叫后端控制器）

6.Controller执行完成返回ModelAndView

7.DispatcherServlet将ModelAndView传给ViewReslover视图解析器

8.ViewReslover解析器后返回具体视图

9.DispatchServlet根据View进行视图渲染（将模型数据填充至视图中），响应给用户

IOC

AOP

自定义缓存注解：基于分布式锁和AOP实现

1.resultType，resultMap

2.association对一，collection对多

3.javaType，ofType对多

和java一样extends

1.resultMap可以自定义结果集比如一些映射或者级联关系的结果

2.resultType返回的是一个Pojo类的结果集使用

3.有List字段就使用resultMap，然后指定一个collection的关联关系

1.#{}是预编译的，${}不是预编译的

2.#{}预编译成?，${}是直接字符串拼接的

3.预编译可以防止SQL注入

4.#{}不需要做数据类型转换，${}如果传入数值类型需要'${a}'转换成字符串

5.传入一个参数时#{}可以使用任意参数名接收参数，而${}默认使用${value}接收，在Mapper接口使用@Param("")指定参数名

1.提取公共SQL，指定一个id，别处要使用就refid="id"

1.配置文件的形式

2.@Bean注解

3.BeanFactory

1.双写模式

2.失效模式

3.双删模式★

4.阿里开源canal中间件（主从复制思想，伪装成一个从机，然后通过读取Mysql中继日志，进行数据同步）

1.String

2.set

3.zset

4list：双向连表

5.hash：由多对kv组成

1.登录校验的token存储在redis中

2.购物车商品实时价格

3.用户的购物车信息

5.分布式锁

6.订单的唯一ID

缓存问题（2）

1.添加过期时间防止死锁，set key value ex 30 nx

2.可重入，hash + lua脚本 防止误删并且保证了原子性

3.解锁：先判断再删除

自动续期

1.为了防止缓存击穿，添加分布式锁

1.基于内存

2.非阻塞IO，多路IO复用

1.被动删除

2.主动删除

3.当前已用内存超过maxmemory值时，触发主动清除策略

1.针对有过期时间的key/针对所有key，使用lru算法淘汰

2.针对有过期时间的key/所有的key，使用lfu算法

1.RDB：二进制快照方式，直接把内存中的数据持久化到一个dump.rdb文件中

2.AOF：日志拼接方式把执行的命令写到一个.aof文件中

1.代码逻辑写死

Redis集群有16384个哈希槽，每个key通 过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

1.禁止外网访问 bind 127.0.0.1

2.设置密码

1.在对首页及搜索页面商品进行增删改操作的时候，向es同步数据时使用了。

2.购物车中价格变化，用缓存+MQ实现了实时价格

3.订单提交的分布式事务：MQ+补偿机制

4.延时队列和死信队列实现定时关单、定时解锁库存

5.用户注册成功后，如果三天没有登录就发短信进行提醒

6.用户发起退款，如果三天没有得到处理则通知相关运营人员

1.消息中间件

2.延时队列

3.死信队列

用过类似的消息中间件，RabbitMQ。

1.生产者确认

2.消费者确认：basicAck

3.消息持久化

1.如果是数据库的写入操作，就先根据查询一下，如果已经存在，就不再执行insert操作，可以执行update

2.如果是写入redis，redis的set操作本身具有幂等性，所以不用担心

3.生成一个唯一id，防止表单重复提交

如果说积压了几百万的数据的话，这个时候修复了消费者，让他恢复速度，那么也得等几个小时才能恢复，所以我们采取的措施是临时的紧急扩容

1.先修复消费者的问题，确保其恢复消费速度，然后将现有的消费者都停掉

2.新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量

3.然后写一个临时的分发数据的consumer程序，部署上去消费积压的数据，消费之后不做耗时的处理，直接轮询写入临时建立好的10倍数量的queue

4.接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时的queue的数据

5.这个做法相当与临时将队列和消费者资源扩容10倍，以正常10倍的速度来消费数据

6.等快速消费完积压的数据之后，就恢复原先的部署架构，重新用原先的消费者机器来消费消息

以项目为例

1.TM向TC注册一个全局事务，TC生成一个全局事务，并返回一个全局事务的唯一标识XID

2.XID会在微服务的调用链路中传播

3.RM向TC注册一个本地事务，作为XID相对应的全局事务的一个分支事务

4.TM向TC发起XID相应的全局事务的提交或回滚

5.TC驱动RM完成XID相应的全局事务下的所有分支事务的提交和回滚

1.synchronized是JDK提供的关键字，lock是一个接口

2.lock支持读共享，轻量级锁，更加灵活；synchronized重量级锁（读写排他）

3.lock可以避免出现死锁(tryLock())，synchronized无法避免死锁

4.lock支持中断，synchronized不支持中断

5.都是可重入锁

6.lock支持非公平和公平锁，sychronized只支持非公平

7.lock发生异常时需要手动释放锁，synchronized发生异常自动释放锁

8.lock性能高，sychronized性能低

1.volatile只能保证变量的修改可见性不能保证原子性，sychronized可以保证原子性和可见性

2.volatile不会造成线程的阻塞，sychronized可能会造成线程的阻塞

3.volatile只能用在变量上，sychronized可以用在变量、方法、和类上

4.volatile本质是JVM当前变量在工作内存中的值是不确定的，需要从主内存中读取，
   sychronized是锁定当前变量，只有当前线程可以访问，其他线程会被阻塞

1.核心线程数corePoolSize

2.最大线程数maximumPoolSize

3.多余空闲线程存活时间keepAliveTime

4.存活时间的单位unit

5.任务队列workQueue

6.线程工厂threadFactory，一般使用默认的

7.拒绝策略handler（2）

Executors.newFixedThreadPool：创建一个固定大小的线程池，可控制并发的线程数，超出的线程会在队列中等待；
Executors.newCachedThreadPool：创建一个可缓存的线程池，若线程数超过处理所需，缓存一段时间后会回收，若线程数不够，则新建线程；
Executors.newSingleThreadExecutor：创建单个线程数的线程池，它可以保证先进先出的执行顺序；
Executors.newScheduledThreadPool：创建一个可以执行延迟任务的线程池；
Executors.newSingleThreadScheduledExecutor：创建一个单线程的可以执行延迟任务的线程池；
Executors.newWorkStealingPool：创建一个抢占式执行的线程池（任务执行顺序不确定）【JDK 1.8 添加】。
ThreadPoolExecutor：最原始的创建线程池的方式，它包含了 7 个参数可供设置。

1.通过jstack命令查看：jstack/jvisualvm命令中显示发生了死锁的线程

2.或者两个线程去操作数据库时，数据库发生了死锁，可以查询死锁情况的SQL

1.死锁原因

2.注意

join，yeild

1.创建

2.就绪

3.运行

4.等待

5.休眠

6.消亡

普通线程

守护线程

1.栈溢出异常，可能导致OutOfMemory

2.堆溢出异常

3.元空间异常

解决

1.局部数组过大

2.递归调用层次太多

3.指针或数组越界

1.引用计数法（基本不用）

2.标记清除法（老年代）

3.标记整理清除法（老年代）

4.复制算法（年轻代）

遵循"先进后出/后进先出"原则，栈顶就是当前的方法，执行完毕就弹出栈，依次执行下面的方法

1.引用计数法：当一个变量或者实例没有被引用时（四种引用）

2.可达性分析算法：扫描堆中的对象，看是否能够沿着GC Root对象为起点的引用链找到该对象，找不到，表示可以回收

大对象或者长期存活的对象

1.启动引导类加载器

2.拓展类加载器

3.应用类加载器

4.自定义类加载器

1.当某个类加载器要加载.class文件时，会先把这个任务委托给自己的上一级加载器

作用

存静态变量、类信息、常量

JDK1.7：永久代PermGen

JDK1.8：元空间Metaspace

运行时常量池

1.微服务是一种概念，boot是一种具体实现

1.自动配置

2.依赖管理，只需引入一个框架的场景启动器即可使用

1.服务注册与发现，配置nacos

2.负载均衡服务调用Ribbon

3.服务接口调用OpenFeign(支持MVC注解)

4.断路器Hystrix，SpringCloud Alibaba Sentinel

5.网关gateway

6.分布式链路追踪 sleuth+zipkin

实现方式

实现步骤

1.和zookeeper一样的一个少数服从多数的思路,假如部署5台redis，获取锁的时候，超过半数获取到锁，就算成功成功获取到锁

2.锁必须要有一个超时强制释放机制，避免服务器宕机，锁无法得到释放

3.取锁之前和取锁之后都获取当前时间，endTime-beginTIme > TTL(超时时间)，表示刚获取到锁就过期了，获取锁失败

4.如果获取锁失败，那么要在所有redis节点执行释放锁操作。避免由于超时情况，有些节点获取到锁，无法得到释放

1.宕机重启之后，2个客户端拿到同一把锁。---延时重启

2.时钟跳跃

3.客户端大延迟(比如full GC)，2个客户端拿到同一把锁

网关经过各个过滤器之后将符合断言的请求路由到具体的微服务接口

1.一致性

2.可用性

3.分区容错性

1.通过set方法可以直接存入一个参数

2.get方法可以直接拿出参数

3.真正的局部变量是ThreadLocalMap<ThreadLocal,载荷值>

4.先获取当前线程，T t

5.ThreadLocalMap map = getMap(t)

1.路由id：唯一标识

2.uri：lb://ums-service

3.predicates:
            - Path=/ums/**

4.filter过滤器

负载均衡配置

1.全局过滤器

2.局部过滤器

1.需求分析

2.用户信息使用拦截器同一获取

3.新增购物车

4.查询购物车

1.订单确认(异步编排优化获取)

2.订单提交(异步编排)

3.退单

使用UUID随机生成的user-key作为数据库的userId存放在数据库中。

实时价格：使用缓存+MQ的最终一致性

idworker：主机和进程的机器码

先经过网关

1.获取用户的请求路径，判断该路径是否在拦截名单中；不在名单中就直接放行

2.获取请求中的token，判断是否同步请求；同步请求从cookie中获取，异步请求从请求头中获取
（一个网站有很多cookie，使用cookie方式传递token，网络传输压力太大）

3.判断token是否为空，为空就设置状态码302并重定向到登录页面

4.使用公钥解析token，并判断IP地址是否相同，不相同就重定向到登录界面（解析出现异常也重定向到登录）

5.将登录信息传递给后续服务，后续服务不用再解析JWT了

6.放行

1.为了防止缓存击穿，添加的分布式锁，基于Redisson实现

1.CPU密集型

2.IO密集型

1.后台系统使用seata

2.前台系统MQ的最终一致性+补偿机制

1.商品表10w记录

2.用户20w

3.订单8w

4.服务器60-70台

5.并发600-1000，甲方数据拿不到

6.系统出问题平时怎么查看？

7.生产环境部署：docker

1.三大范式

2.根据页面分析所需的数据，设置一个冗余字段备用（以购物车为例）