明天来分享一篇字节跳动抖音电商的面经，心愿对小伙伴们有所帮忙~

文章目录：

HashMap的put办法

put办法过程：

  1. 如果table没有初始化就先进行初始化过程
  2. 应用hash算法计算key的索引
  3. 判断索引处有没有存在元素，没有就直接插入
  4. 如果索引处存在元素，则遍历插入，有两种状况，一种是链表模式就间接遍历到尾端插入，一种是红黑树就依照红黑树结构插入
  5. 链表的数量大于阈值8，就要转换成红黑树的构造
  6. 增加胜利后会查看是否须要扩容

HashMap的扩容过程

1.8扩容机制：当元素个数大于threshold时，会进行扩容，应用2倍容量的数组代替原有数组。采纳尾插入的形式将原数组元素拷贝到新数组。1.8扩容之后链表元素绝对地位没有变动，而1.7扩容之后链表元素会倒置。

因为数组的容量是以2的幂次方扩容的，那么一个Entity在扩容时，新的地位要么在原地位，要么在原长度+原地位的地位。起因是数组长度变为原来的2倍，体现在二进制上就是多了一个高位参加数组下标计算。也就是说，在元素拷贝过程不须要从新计算元素在数组中的地位，只须要看看原来的hash值新增的那个bit是1还是0，是0的话索引没变，是1的话索引变成“原索引+oldCap”（依据e.hash & (oldCap - 1) == 0判断） 。

这样能够省去从新计算hash值的工夫，而且因为新增的1bit是0还是1能够认为是随机的，因而resize的过程会平均的把之前的抵触的节点扩散到新的bucket。

自定义协定怎么解决粘包问题

  1. 固定长度的数据包。为字节流加上自定义固定长度报头，报头中蕴含字节流长度，而后一次send到对端，对端在接管时，先从缓存中取出定长的报头，而后再取实在数据。
  2. 以指定字符串为包的完结标记。当字节流中遇到非凡的符号值时就认为到一个包的结尾。
  3. header + body格局。这种格局的包个别分为两局部，即包头和包体，包头是固定大小的，且包头中含有一个字段来表明包体有多大。

LeetCode129题(求根节点到叶节点数字之和)

深度优先搜寻。从根节点开始，遍历每个节点，如果遇到叶子节点，则将叶子节点对应的数字加到数字之和。如果以后节点不是叶子节点，则计算其子节点对应的数字，而后对子节点递归遍历。

没有艰难的题目，只有怯懦的刷题人！

//  输出: [1,2,3]//     1//    / \//   2   3// 输入: 25class Solution {    public int sumNumbers(TreeNode root) {        if (root == null) {            return 0;        }        return sumNumbersHelper(root, 0);    }    private int sumNumbersHelper(TreeNode node, int sum) {        if (node == null) {            return 0;        }        if (sum > Integer.MAX_VALUE / 10 || (sum == Integer.MAX_VALUE / 10 && node.val > Integer.MAX_VALUE % 10)) {            throw new IllegalArgumentException("exceed max int value");        }        sum = sum * 10 + node.val;        if (node.left == null && node.right == null) {            return sum;        }        return sumNumbersHelper(node.right, sum) + sumNumbersHelper(node.left, sum);    }}

MySQL的索引构造

MySQL 数据库应用最多的索引类型是BTREE索引，底层基于B+树数据结构来实现。

B+ 树是基于B 树和叶子节点程序拜访指针进行实现，它具备B树的平衡性，并且通过程序拜访指针来进步区间查问的性能。

在 B+ 树中，节点中的 key 从左到右递增排列，如果某个指针的左右相邻 key 别离是 keyi 和 keyi+1，则该指针指向节点的所有 key 大于等于 keyi 且小于等于 keyi+1。

进行查找操作时，首先在根节点进行二分查找，找到key所在的指针，而后递归地在指针所指向的节点进行查找。直到查找到叶子节点，而后在叶子节点上进行二分查找，找出 key 所对应的数据项。

为什么用B+树

B+树的特点就是够矮够胖，能无效地缩小拜访节点次数从而进步性能。

二叉树：二分查找树，尽管也有很好的查找性能log2N，然而当N比拟大的时候，树的深度比拟高。数据查问的工夫次要依赖于磁盘IO的次数，二叉树深度越大，查找的次数越多，性能越差。最坏的状况会进化成链表。所以，B+树更适宜作为MySQL索引构造。

B树：因为B+的分支结点存储着数据，咱们要找到具体的数据，须要进行一次中序遍历按序来扫，而因为B+树的数据都存储在叶子结点中，叶子结点均为索引，不便扫库，只须要扫一遍叶子结点即可。所以B+树更加适宜在区间查问的状况，而在数据库中基于范畴的查问是十分频繁的，所以B+树更适宜用于数据库索引。

having的作用

having 用来分组查问后指定一些条件来输入查问后果，having作用和where相似，然而having只能用在group by场合，并且必须位于group by之后order by之前。

SELECT cust_id, COUNT(*) AS ordersFROM ordersGROUP BY cust_idHAVING COUNT(*) >= 2;

聚簇索引

汇集索引的叶子节点就是整张表的行记录。InnoDB 主键应用的是聚簇索引。汇集索引要比非汇集索引查问效率高很多。汇集索引叶子节点的存储是逻辑上间断的，应用双向链表连贯，叶子节点依照主键的程序排序，因而对于主键的排序查找和范畴查找速度比拟快。

对于InnoDB来说，汇集索引个别是表中的主键索引，如果表中没有显示指定主键，则会抉择表中的第一个不容许为NULL的惟一索引。如果没有主键也没有适合的惟一索引，那么innodb外部会生成一个暗藏的主键作为汇集索引，这个暗藏的主键长度为6个字节，它的值会随着数据的插入自增。

聚簇索引相比非聚簇索引的长处

  1. 数据拜访更快，因为聚簇索引将索引和数据保留在同一个B+树中，因而从聚簇索引中获取数据比非聚簇索引更快；
  2. 汇集索引叶子节点的存储是逻辑上间断的，所以对于主键的排序查找和范畴查找速度会更快。

线程池的七大参数

ThreadPoolExecutor 的通用构造函数：

public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler);
  • corePoolSize：当有新工作时，如果线程池中线程数没有达到线程池的根本大小，则会创立新的线程执行工作，否则将工作放入阻塞队列。当线程池中存活的线程数总是大于 corePoolSize 时，应该思考调大 corePoolSize。
  • maximumPoolSize：当阻塞队列填满时，如果线程池中线程数没有超过最大线程数，则会创立新的线程运行工作。否则依据回绝策略解决新工作。非核心线程相似于长期借来的资源，这些线程在闲暇工夫超过 keepAliveTime 之后，就应该退出，防止资源节约。
  • BlockingQueue：存储期待运行的工作。
  • keepAliveTime：非核心线程闲暇后，放弃存活的工夫，此参数只对非核心线程无效。设置为0，示意多余的闲暇线程会被立刻终止。

  • TimeUnit：工夫单位

    TimeUnit.DAYSTimeUnit.HOURSTimeUnit.MINUTESTimeUnit.SECONDSTimeUnit.MILLISECONDSTimeUnit.MICROSECONDSTimeUnit.NANOSECONDS

  • ThreadFactory：每当线程池创立一个新的线程时，都是通过线程工厂办法来实现的。在 ThreadFactory 中只定义了一个办法 newThread，每当线程池须要创立新线程就会调用它。

    public class MyThreadFactory implements ThreadFactory {    private final String poolName;        public MyThreadFactory(String poolName) {        this.poolName = poolName;    }        public Thread newThread(Runnable runnable) {        return new MyAppThread(runnable, poolName);//将线程池名字传递给构造函数，用于辨别不同线程池的线程    }}

  • RejectedExecutionHandler：当队列和线程池都满了时，依据回绝策略解决新工作。

    AbortPolicy：默认的策略，间接抛出RejectedExecutionExceptionDiscardPolicy：不解决，间接抛弃DiscardOldestPolicy：将期待队列队首的工作抛弃，并执行当前任务CallerRunsPolicy：由调用线程解决该工作

线程池的运行过程

mysql的四个隔离级别

先理解下几个概念：脏读、不可反复读、幻读。

  • 脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。
  • 不可反复读是指在对于数据库中的某行记录，一个事务范畴内屡次查问却返回了不同的数据值，这是因为在查问距离，另一个事务批改了数据并提交了。
  • 幻读是当某个事务在读取某个范畴内的记录时，另外一个事务又在该范畴内插入了新的记录，当之前的事务再次读取该范畴的记录时，会产生幻行，就像产生幻觉一样，这就是产生了幻读。

不可反复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可反复读则是读取了前一事务提交的数据。
幻读和不可反复读都是读取了另一条曾经提交的事务，不同的是不可反复读的重点是批改，幻读的重点在于新增或者删除。

事务隔离就是为了解决下面提到的脏读、不可反复读、幻读这几个问题。

MySQL数据库为咱们提供的四种隔离级别：

  • Serializable (串行化)：通过强制事务排序，使之不可能互相抵触，从而解决幻读问题。
  • Repeatable read (可反复读)：MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行，解决了不可反复读的问题。
  • Read committed (读已提交)：一个事务只能看见曾经提交事务所做的扭转。可防止脏读的产生。
  • Read uncommitted (读未提交)：所有事务都能够看到其余未提交事务的执行后果。

查看隔离级别：

select @@transaction_isolation;

设置隔离级别：

set session transaction isolation level read uncommitted;

dubbo的负载平衡策略

Dubbo提供了多种平衡策略，默认为Random随机调用。

Random LoadBalance

基于权重的随机负载平衡机制。

  • 随机，按权重设置随机概率
  • 在一个截面上碰撞的概率高，但调用量越大散布越平均，而且按概率使用权重后也比拟平均，有利于动静调整提供者权重

RoundRobin LoadBalance

基于权重的轮询负载平衡机制，不举荐。

  • 轮循，按公约后的权重设置轮循比率
  • 存在慢的提供者累积申请的问题，比方：第二台机器很慢，但没挂，当申请调到第二台时就卡在那，长此以往，所有申请都卡在调到第二台上

LeastActive LoadBalance

  • 起码沉闷调用数，雷同沉闷数的随机，沉闷数指调用前后计数差
  • 使慢的提供者收到更少申请，因为越慢的提供者的调用前后计数差会越大

ConsistentHash LoadBalance

  • 一致性 Hash，雷同参数的申请总是发到同一提供者。(如果你须要的不是随机负载平衡，是要一类申请都到一个节点，那就走这个一致性hash策略。)
  • 当某一台提供者挂时，本来发往该提供者的申请，基于虚构节点，平摊到其它提供者，不会引起激烈变动。
参考资料：https://blog.csdn.net/yjn1995...

java的动静代理

动静代理：代理类在程序运行时创立，在内存中长期生成一个代理对象，在运行期间对业务办法进行加强。

JDK实现代理只须要应用newProxyInstance办法：

static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces,   InvocationHandler h )

参数阐明：

  • ClassLoader loader:指定以后指标对象应用的类加载器
  • Class<?>[] interfaces:指标对象实现的接口的类型
  • InvocationHandler h:当代理对象调用指标对象的办法时，会触发事件处理器的invoke办法()

以下是JDK动静代理Demo：

public class DynamicProxyDemo {    public static void main(String[] args) {        //被代理的对象        MySubject realSubject = new RealSubject();        //调用处理器        MyInvacationHandler handler = new MyInvacationHandler(realSubject);        MySubject subject = (MySubject) Proxy.newProxyInstance(realSubject.getClass().getClassLoader(),                realSubject.getClass().getInterfaces(), handler);        System.out.println(subject.getClass().getName());        subject.rent();    }}interface MySubject {    public void rent();}class RealSubject implements MySubject {    @Override    public void rent() {        System.out.println("rent my house");    }}class MyInvacationHandler implements InvocationHandler {    private Object subject;    public MyInvacationHandler(Object subject) {        this.subject = subject;    }    @Override    public Object invoke(Object object, Method method, Object[] args) throws Throwable {        System.out.println("before renting house");        //invoke办法会拦挡代理对象的办法调用        Object o = method.invoke(subject, args);        System.out.println("after rentint house");        return o;    }}

Spring哪里用到了动静代理？

Spring AOP 是通过动静代理技术实现的。

什么是AOP？

AOP，面向切面编程，作为面向对象的一种补充，将公共逻辑（事务管理、日志、缓存等）封装成切面，跟业务代码进行拆散，能够缩小零碎的反复代码和升高模块之间的耦合度。切面就是那些与业务无关，但所有业务模块都会调用的公共逻辑。

动静代理的实现形式？

动静代理技术的实现形式有两种：

  1. 基于接口的 JDK 动静代理。
  2. 基于继承的 CGLib 动静代理。在Spring中，如果指标类没有实现接口，那么Spring AOP会抉择应用CGLIB来动静代理指标类。

说一下CGlib动静代理

CGLIB（Code Generator Library）是一个弱小的、高性能的代码生成库。其被广泛应用于AOP框架（Spring、dynaop）中，用以提供办法拦挡操作。CGLIB代理次要通过对字节码的操作，为对象引入间接级别，以管制对象的拜访。

CGLib 动静代理绝对于 JDK 动静代理局限性就小很多，指标对象不须要实现接口，底层是通过继承指标对象产生代理子对象。

MQ如何保障音讯不会失落？

音讯失落场景：生产者生产音讯到RabbitMQ Server音讯失落、RabbitMQ Server存储的音讯失落和RabbitMQ Server到消费者音讯失落。

音讯失落从三个方面来解决：生产者确认机制、消费者手动确认音讯和长久化。以下实现以 RabbitMQ 为例。

生产者确认机制

生产者发送音讯到队列，无奈确保发送的音讯胜利的达到server。

解决办法：

  1. 事务机制。在一条音讯发送之后会使发送端阻塞，期待RabbitMQ的回应，之后能力持续发送下一条音讯。性能差。
  2. 开启生产者确认机制，只有音讯胜利发送到交换机之后，RabbitMQ就会发送一个ack给生产者（即便音讯没有Queue接管，也会发送ack）。如果音讯没有胜利发送到交换机，就会发送一条nack音讯，提醒发送失败。

在 Springboot 是通过 publisher-confirms 参数来设置 confirm 模式：

spring:    rabbitmq:           #开启 confirm 确认机制        publisher-confirms: true

在生产端提供一个回调办法，当服务端确认了一条或者多条音讯后，生产者会回调这个办法，依据具体的后果对音讯进行后续解决，比方从新发送、记录日志等。

// 音讯是否胜利发送到Exchangefinal RabbitTemplate.ConfirmCallback confirmCallback = (CorrelationData correlationData, boolean ack, String cause) -> {            log.info("correlationData: " + correlationData);            log.info("ack: " + ack);            if(!ack) {                log.info("异样解决....");            }    };rabbitTemplate.setConfirmCallback(confirmCallback);

Return音讯机制

生产者确认机制只确保音讯正确达到交换机，对于从交换机路由到Queue失败的音讯，会被抛弃掉，导致音讯失落。

对于不可路由的音讯，能够通过 Return 音讯机制来解决。

Return音讯机制提供了回调函数 ReturnCallback，当音讯从交换机路由到Queue失败才会回调这个办法。须要将mandatory 设置为 true ，能力监听到路由不可达的音讯。

spring:    rabbitmq:        #触发ReturnCallback必须设置mandatory=true, 否则Exchange没有找到Queue就会抛弃掉音讯, 而不会触发ReturnCallback        template.mandatory: true

通过 ReturnCallback 监听路由不可达音讯。

    final RabbitTemplate.ReturnCallback returnCallback = (Message message, int replyCode, String replyText, String exchange, String routingKey) ->            log.info("return exchange: " + exchange + ", routingKey: "                    + routingKey + ", replyCode: " + replyCode + ", replyText: " + replyText);rabbitTemplate.setReturnCallback(returnCallback);

当音讯从交换机路由到Queue失败时，会返回 return exchange: , routingKey: MAIL, replyCode: 312, replyText: NO_ROUTE。

消费者手动音讯确认

有可能消费者收到音讯还没来得及解决MQ服务就宕机了，导致音讯失落。因为音讯者默认采纳主动ack，一旦消费者收到音讯后会告诉MQ Server这条音讯曾经解决好了，MQ 就会移除这条音讯。

解决办法：消费者设置为手动确认音讯。消费者解决完逻辑之后再给broker回复ack，示意音讯曾经胜利生产，能够从broker中删除。当音讯者生产失败的时候，给broker回复nack，依据配置决定从新入队还是从broker移除，或者进入死信队列。只有没收到消费者的 acknowledgment，broker 就会始终保留着这条音讯，但不会 requeue，也不会调配给其余 消费者。

消费者设置手动ack：

#设置生产端手动 ackspring.rabbitmq.listener.simple.acknowledge-mode=manual

音讯解决完，手动确认：

    @RabbitListener(queues = RabbitMqConfig.MAIL_QUEUE)    public void onMessage(Message message, Channel channel) throws IOException {        try {            Thread.sleep(5000);        } catch (InterruptedException e) {            e.printStackTrace();        }        long deliveryTag = message.getMessageProperties().getDeliveryTag();        //手工ack；第二个参数是multiple，设置为true，示意deliveryTag序列号之前（包含本身）的音讯都曾经收到，设为false则示意收到一条音讯        channel.basicAck(deliveryTag, true);        System.out.println("mail listener receive: " + new String(message.getBody()));    }

当音讯生产失败时，生产端给broker回复nack，如果consumer设置了requeue为false，则nack后broker会删除音讯或者进入死信队列，否则音讯会从新入队。

长久化

如果RabbitMQ服务异样导致重启，将会导致音讯失落。RabbitMQ提供了长久化的机制，将内存中的音讯长久化到硬盘上，即便重启RabbitMQ，音讯也不会失落。

音讯长久化须要满足以下条件：

  1. 音讯设置长久化。公布音讯前，设置投递模式delivery mode为2，示意音讯须要长久化。
  2. Queue设置长久化。
  3. 交换机设置长久化。

当公布一条音讯到交换机上时，Rabbit会先把音讯写入长久化日志，而后才向生产者发送响应。一旦从队列中生产了一条音讯的话并且做了确认，RabbitMQ会在长久化日志中移除这条音讯。在生产音讯前，如果RabbitMQ重启的话，服务器会主动重建交换机和队列，加载长久化日志中的音讯到相应的队列或者交换机上，保障音讯不会失落。

面经原贴来自牛客网，我本人整顿的答案，有问题的小伙伴能够在评论区留言指出。

原帖链接：https://www.nowcoder.com/disc...