1.二叉树
前序遍历：根节点->递归访问左子树->递归访问右子树 中序遍历：递归访问左子树->根节点->递归访问右子树
2.什么时候用 == ，什么时候用 equals ？
==：对于基本数据类型来说，== 比较的是值。
对于引用数据类型来说，== 比较的是对象的内存地址。
equals：不能用于判断基本数据类型的变量，只能用来判断两个对象是否相等。
HashCode（）和equals（）方法的关系：
如果 HashSet 在对比的时候，同样的 hashCode 有多个对象，它会继续使用 equals() 来判断是否真的相同。也就是说 hashCode 帮助我们大大缩小了查找成本。
为什么重写 equals() 时必须重写 hashCode() 方法？
因为两个相等的对象的 hashCode 值必须是相等。也就是说如果 equals 方法判断两个对象是相等的，那这两个对象的 hashCode 值也要相等。
如果重写 equals() 时没有重写 hashCode() 方法的话就可能会导致 equals 方法判断是相等的两个对象，hashCode 值却不相等。
3.常见的排序算法以及时间复杂度
4.Cookie和Session的区别
Cookie 存放在客户端，一般用来保存用户信息。
Session 的主要作用就是通过服务端记录用户的状态。
5.事务
事务是指逻辑上的一组操作，组成这组操作的各个单元，要不全成功要不全失败。
6.Redis生产问题
1.缓存穿透
缓存穿透说简单点就是大量请求的 key 是不合理的，根本不存在于缓存中，也不存在于数据库中 。这就导致这些请求直接到了数据库上，根本没有经过缓存这一层，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。
解决方法：做好参数校验①缓存无效的key，设置过期时间②布隆过滤器③接口限流
2.缓存击穿
请求的 key 对应的是 热点数据 ，该数据 存在于数据库中，但不存在于缓存中（通常是因为缓存中的那份数据已经过期） 。这就可能会导致瞬时大量的请求直接打到了数据库上，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。
解决方法：①永不过期②提前预热（提前存入缓存）③加锁
3.缓存雪崩
缓存在同一时间大面积的失效，导致大量的请求都直接落到了数据库上，对数据库造成了巨大的压力。 这就好比雪崩一样，摧枯拉朽之势，数据库的压力可想而知，可能直接就被这么多请求弄宕机了。
解决方法：
针对Redis不可用：①Redis集群②多级缓存
针对缓存失效：①设置随机过期时间②提前预热③持久缓存策略
7.乐观锁与悲观锁
乐观锁总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，无需加锁也无需等待，只是在提交修改的时候去验证对应的资源（也就是数据）是否被其它线程修改了（具体方法可以使用版本号机制或 CAS 算法）。
悲观锁总是假设最坏的情况，认为共享资源每次被访问的时候就会出现问题(比如共享数据被修改)，所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。
8.重载和重写的区别
1.重载就是一个方法能够根据输入数据的不同，做出不同的处理。 2.重写就是当子类继承自父类的相同方法，输入数据一样，但要做出有别于父类的响应时，你就要覆盖父类的方法。
9.8种基本数据类型
1.6种数字类型 4种整数类型 byte、short、int、long 2种浮点类型 float、double 2.1种字符类型 char 3.1种布尔类型 boolean
10.数据库事务隔离级别
1.READ-UNCOMMITTED(读取未提交) ：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。 2.READ-COMMITTED(读取已提交) ：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。 3.REPEATABLE-READ(可重复读) ：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。 4.SERIALIZABLE(可串行化) ：最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
11.接口和抽象类
1.共同点
- 实例化：接口和抽象类都不能直接实例化，只能被实现（接口）或继承（抽象类）后才能创建具体的对象。
-
- 抽象方法：接口和抽象类都可以包含抽象方法。抽象方法没有方法体，必须在子类或实现类中实现。
