Java面试题总结

3-25面试题

对象在内存中怎么存储的？常量池是什么，在哪个位置？

Java中对象到底存在堆中还是栈中

• 如果是基本数据类型，byte、short、int、long、flostring 类提供的各种操作函数大致分为八类：构造器和析构器、大小和容量、元素存取、字 符串比较、字符串修改、字符串接合、I/O 操作以及搜索和查找。at、double、char，如果是在方法中声明，则存储在栈中，其它情况都是在堆中（比方说类的成员变量就在堆中）；
• 除了基本数据类型之外的对象，JVM会在堆中创建对象，对象的引用存于虚拟机栈中的局部变量表中
• 并不是所有的对象都在堆中存储，可以走栈上分配，在不在栈上分配取决于Hotspot的一个优化技术:“逃逸分析”

常量池，是指在编译期被确定，并被保存在已编译的.class文件中的一些数据。常量池中包含了关于类、接口、方法中的常量和字符串常量及符号引用。

常量池的出现是为了防止过于频繁的创建与销毁对象而影响系统性能，它实现了对象的共享。**

如字符串常量池，会在编译阶段就把所有的字符串文字放到一个常量池中，这样的好处有：

节省内存空间：常量池中所有相同的字符串常量被合并，只占用一个空间。

节省运行时间：比较字符串时，比equals()快。对于两个引用变量，只用判断引用是否相等，也就可以判断实际值是否相等。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vsjb2qBF-1679920736796)(C:\Users\CLOSER\AppData\Roaming\Typora\typora-user-images\image-20230325211624601.png)]

String类有哪些函数？

string 类提供的各种操作函数大致分为八类：构造器和析构器、大小和容量、元素存取、字 符串比较、字符串修改、字符串接合、I/O 操作以及搜索和查找。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8riTGhwX-1679920736799)(C:\Users\CLOSER\AppData\Roaming\Typora\typora-user-images\image-20230325212056066.png)]

redis五大数据类型

1. String：字符串类型
2. List：列表类型
3. Set：无序集合类型
4. ZSet：有序集合类型
5. Hash：哈希表类型

Set集合

Redis中列表和集合都可以用来存储字符串，但是**「Set是不可重复的集合，而List列表可以存储相同的字符串」**，Set集合是无序的这个和后面讲的ZSet有序集合相对。

Set的底层实现是**「ht和intset」**

Set集合的应用场景可以用来**「去重、抽奖、共同好友、二度好友」**等业务类型。接下来模拟一个添加好友的案例实现：

string，StringBuffer，StringBuilder区别

对于String来说，是把数据存放在了常量池中，因为所有的String，默认都是以常量形式保存，且由final修饰，因此在线程池中它是线程安全的。因为每一个String当被创建好了以后，他就不再发生任何变化，但是它的执行速度是最差的。
我们要创建String的时候，他在常量池中对这些信息进行处理，如果在程序中出现了大量字符串拼接的工作，效率是非常底下的。
因此使用场景是在少量字符串操作的时候才建议直接使用String来操作。

StirngBuffer：（效率不如StringBuilder，但远比String要高）

StringBuffer相对于StringBuilder效率要相对低一点，但也远比String要高的多。效率低的原因：对于StringBuffer来说更多的考虑到了多线程的情况，在进行字符串操作的时候，它使用了synchronize关键字，对方法进行了同步处理。
因此StringBuffer适用于多线程环境下的大量操作。

StringBuilder：（没有考虑线程安全问题）

线程安全与线程不安全：
在进行多线程处理的时候，如果多个线程对于这一个对象同时产生操作，会产生预期之外的结果。对于StringBuilder来说，执行效率虽然高，但是因为线程不安全，所以不建议在多线程的环境下对同一个StringBuilder对象进行操作。
因此StringBuilder适用于单线程环境下的大量字符串操作。

http协议

超文本传输协议，明文传输不太安全

依赖于http ip 这样的传输层，更安全https 换个传输层协议 应用层协议

基于请求和相应模式无状态的协议，是一个格式规范

二叉树如何遍历

层序遍历，放入一个队列，然后看他是否有左孩子和右孩子有的话，就加到队列中来

http协议如何实现安全的呢

HTTP的缺点就是不安全，它是互联网传统的传输协议，采用明文传输的方式，换句话说就是数据通过http协议进行传输是一个“裸奔”的状态，没有任何加密保护，很容易就被第三方进行窃取或篡改。

HTTPS是以安全为目标的HTTP通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性，这一切都是靠SSL证书来实现的。

缺页中断

缺页：如果进程被调度，该进程需要使用的外存页（数据）不存在于数据块中，这个现象就叫做缺页。如果这个数据此时不在，就会将这个数据从加入到数据块首部。缺页本身是一种中断，与一般的中断一样，需要经过4个处理步骤：

保护CPU现场
分析中断原因
转入缺页中断处理程序进行处理
恢复CPU现场，继续执行

页面置换算法：
进程运行过程中，如果发生缺页中断，而此时内存中又没有空闲的数据块，为了能够把所缺的页面装入内存，系统必须从内存中选择一页调出到磁盘的对换区。此时把那个页面换出则需要根据一定的页面置换算法(PPA)来确定。

先进先出调度算法（FIFO）
最近最不常用调度算法（LRU，根据使用频率判断）
最佳置换算法（OPT）

session和cookie的区别

1,Sesssion是服务器端的，cookie是客户端的

服务器端的是安全的，本地端的是不安全的

存数据cookie是有限的，而session是无限的

分页是如何是实现的

• 参数page：为查询的结果集进行一个自动分页.换句话来说，就是指定查询出来的结果集怎么样显示。比如：返回的结果集要显示第1页的数据，并且每页显示10行 —> new Page(1,10)
• 编写一个普通的list查询：需求显示什么样的数据，你只需要给我一个list就行了。参数page会按照你的规则进行分页。
• 继承Page实现自己的分页对象：显示下一行、前一行等等这种功能，你就需要自己写一个分页对象规则。

总结：就是相当于你要自定义一个多表的复杂查询返回来一个list之后，通过你指定的page参数的分页规则，来进行分页

使用了两种方法实现：

1. 简单分页查询：用条件构造器QueryWrapper就能够实现
2. 复杂分页查询：就必须自己手写mapper文件：联表查询

• page：指定分页规则

第二个参数：

• 复杂分页查询：自定义分页：编写SQL查询
• 简单分页查询：条件构造器QueryWrapper

悲观锁于乐观锁

悲观锁**（Pessimistic Concurrency Control）**，第一眼看到它，相信每个人都会想到这是一个悲观的锁。没错，它就是一个悲观的锁。

那这个悲观体现在什么地方呢？悲观是我们人类一种消极的情绪，对应到锁的悲观情绪，悲观锁认为被它保护的数据是极其不安全的，每时每刻都有可能变动，一个事务拿到悲观锁后（可以理解为一个用户），其他任何事务都不能对该数据进行修改，只能等待锁被释放才可以执行。

数据库中的行锁，表锁，读锁，写锁，以及syncronized实现的锁均为悲观锁。

这里再介绍一下什么是数据库的表锁和行锁，以免有的同学对后面悲观锁的实现看不明白。

我们经常使用的数据库是mysql，mysql中最常用的引擎是Innodb，Innodb默认使用的是行锁。而行锁是基于索引的，因此要想加上行锁，在加锁时必须命中索引，否则将使用表锁。
在这里插入图片描述

与悲观相对应，乐观是我们人类一种积极的情绪。乐观锁（Optimistic Concurrency Control）的“乐观情绪”体现在，它认为数据的变动不会太频繁。因此，它允许多个事务同时对数据进行变动。

但是，乐观不代表不负责，那么怎么去负责多个事务顺序对数据进行修改呢？

乐观锁通常是通过在表中增加一个版本(version)或时间戳(timestamp)来实现，其中，版本最为常用。

事务在从数据库中取数据时，会将该数据的版本也取出来(v1)，当事务对数据变动完毕想要将其更新到表中时，会将之前取出的版本v1与数据中最新的版本v2相对比，如果v1=v2，那么说明在数据变动期间，没有其他事务对数据进行修改，此时，就允许事务对表中的数据进行修改，并且修改时version会加1，以此来表明数据已被变动。

1，解决一下超卖问题

从表中可以看到猪肉脯目前的数量只有1个了。在不加锁的情况下，如果A，B同时下单，就有可能导致超卖。

悲观锁解决

利用悲观锁的解决思路是，我们认为数据修改产生冲突的概率比较大，所以在更新之前，我们显示的对要修改的记录进行加锁，直到自己修改完再释放锁。加锁期间只有自己可以进行读写，其他事务只能读不能写。

A下单前先给猪肉脯这行数据（id=1）加上悲观锁（行锁）。此时这行数据只能A来操作，也就是只有A能买。B想买就必须一直等待。

当A买好后，B再想去买的时候会发现数量已经为0，那么B看到后就会放弃购买。

那么如何给猪肉脯也就是id=1这条数据加上悲观锁锁呢？我们可以通过以下语句给id=1的这行数据加上悲观锁

select num from goods where id = 1 for update;

乐观锁解决

使用乐观锁的解决思路是，我们认为数据修改产生冲突的概率并不大，多个事务在修改数据的之前先查出版本号，在修改时把当前版本号作为修改条件，只会有一个事务可以修改成功，其他事务则会失败。

A和B同时将猪肉脯(id=1下面都说是id=1)的数据查出来，然后A先买，A将id=1和version=0作为条件进行数据更新，即将数量-1，并且将版本号+1。

此时版本号变为1。A此时就完成了商品的购买。最后B开始买，B也将id=1和version=0作为条件进行数据更新，但是更新完后，发现更新的数据行数为0，此时就说明已经有人改动过数据，此时就应该提示用户重新查看最新数据购买。

应用场景

悲观锁：因为悲观锁会影响系统吞吐的性能，所以适合应用在写为居多的场景下。

乐观锁：因为乐观锁就是为了避免悲观锁的弊端出现的，所以适合应用在读为居多的场景下。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BdR0okAp-1679920736804)(C:\Users\CLOSER\AppData\Roaming\Typora\typora-user-images\image-20230326221034338.png)]

redis雪崩，穿透，击穿你是怎么理解的？

雪崩

雪崩就是指缓存中大批量热点数据过期后系统涌入大量查询请求，因为大部分数据在Redis层已经失效，请求渗透到数据库层，大批量请求犹如洪水一般涌入，引起数据库压力造成查询堵塞甚至宕机。

1. 将缓存失效时间分散开，比如每个key的过期时间是随机，防止同一时间大量数据过期现象发生，这样不会出现同一时间全部请求都落在数据库层，如果缓存数据库是分布式部署，将热点数据均匀分布在不同Redis和数据库中，有效分担压力，别一个人扛。
2. 简单粗暴，让Redis数据永不过期（如果业务准许，比如不用更新的名单类）。当然，如果业务数据准许的情况下可以，比如中奖名单用户，每期用户开奖后，名单不可能会变了，无需更新。

缓存穿透

对于系统A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。

黑客发出的那 4000 个攻击，缓存中查不到，每次你去数据库里查，也查不到。

举个栗子。数据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数。这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死

解决方式很简单，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。

缓存击穿

缓存击穿，就是说某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。

解决方式也很简单，可以将热点数据设置为永远不过期；或者基于 redis or zookeeper 实现互斥锁，等待第一个请求构建完缓存之后，再释放锁，进而其它请求才能通过该 key 访问数据。

设计模式中单例模式懒汉模式于饿汉模式

单例模式懒汉式和饿汉式区别

单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

1、单例类只能有一个实例。

2、单例类必须自己创建自己的唯一实例。

3、单例类必须给所有其他对象提供这一实例。

明确定义后，看一下代码：

饿汉式

public class SingletonEH {
    /**
     *是否 Lazy 初始化：否
     *是否多线程安全：是
     *实现难度：易
     *描述：这种方式比较常用，但容易产生垃圾对象。
     *优点：没有加锁，执行效率会提高。
     *缺点：类加载时就初始化，浪费内存。
     *它基于 classloder 机制避免了多线程的同步问题，
     * 不过，instance 在类装载时就实例化，虽然导致类装载的原因有很多种，
    * 在单例模式中大多数都是调用 getInstance 方法，
     * 但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，
     * 这时候初始化 instance 显然没有达到 lazy loading 的效果。
     */
    private static SingletonEH instance = new SingletonEH();
    private SingletonEH (){}
    public static SingletonEH getInstance() {
        System.out.println("instance:"+instance);
        System.out.println("加载饿汉式....");
        return instance;
    }
}

饿汉就是类一旦加载，就把单例初始化完成，保证getInstance的时候，单例是已经存在的了。

懒汉模式

public class SingletonLH {
    /**
     *是否 Lazy 初始化：是
     *是否多线程安全：否
     *实现难度：易
     *描述：这种方式是最基本的实现方式，这种实现最大的问题就是不支持多线程。因为没有加锁 synchronized，所以严格意义上它并不算单例模式。
     *这种方式 lazy loading 很明显，不要求线程安全，在多线程不能正常工作。
     */
    private static SingletonLH instance;
    private SingletonLH (){}

    public static SingletonLH getInstance() {
        if (instance == null) {
            instance = new SingletonLH();
        }
        return instance;
    }

}

1、线程安全：

饿汉式天生就是线程安全的，可以直接用于多线程而不会出现问题，

懒汉式本身是非线程安全的，为了实现线程安全有几种写法。

public class SingletonLHsyn {
    /**
     *是否 Lazy 初始化：是
     *是否多线程安全：是
     *实现难度：易
     *描述：这种方式具备很好的 lazy loading，能够在多线程中很好的工作，但是，效率很低，99% 情况下不需要同步。
     *优点：第一次调用才初始化，避免内存浪费。
     *缺点：必须加锁 synchronized 才能保证单例，但加锁会影响效率。
     *getInstance() 的性能对应用程序不是很关键（该方法使用不太频繁）。
     */
    private static SingletonLHsyn instance;
    private SingletonLHsyn (){}
    public static synchronized SingletonLHsyn getInstance() {
        if (instance == null) {
            instance = new SingletonLHsyn();
        }
        return instance;
    }
}

2、资源加载和性能：

饿汉式在类创建的同时就实例化一个静态对象出来，不管之后会不会使用这个单例，都会占据一定的内存，但是相应的，在第一次调用时速度也会更快，因为其资源已经初始化完成。

而懒汉式顾名思义，会延迟加载，在第一次使用该单例的时候才会实例化对象出来，第一次调用时要做初始化，如果要做的工作比较多，性能上会有些延迟，之后就和饿汉式一样了。