//判断是否类型相同
if(this.getClass() != obj.getClass()){
return false;
}
Person person = (Person)obj;
return name.equals(person.name) && age==person.age;
}
}
}
运行结果：
p1.equals(p2) : true; p1(1169863946) p2(1690552137)
set:[(eee, 100), (eee, 100), (aaa, 200)]
结果分析：
我们重写了Person的equals()。但是，很奇怪地发现：HashSet中仍然有重复元素：p1 和 p2。为什么会出现这种情况呢？
这是因为虽然p1 和 p2的内容相等，但是它们的hashCode()不等；所以，HashSet在添加p1和p2的时候，认为它们不相等。
那同时覆盖equals() 和 hashCode()方法呢？
import java.util.*;
import java.lang.Comparable;
/**
-
@desc 比较equals() 返回true 以及 返回false时， hashCode()的值。
*/
public class ConflictHashCodeTest2{
public static void main(String[] args) {
// 新建Person对象，
Person p1 = new Person(“eee”, 100);
Person p2 = new Person(“eee”, 100);
Person p3 = new Person(“aaa”, 200);
Person p4 = new Person(“EEE”, 100);
// 新建HashSet对象
HashSet set = new HashSet();
set.add(p1);
set.add(p2);
set.add(p3);
// 比较p1 和 p2， 并打印它们的hashCode()
System.out.printf(“p1.equals(p2) : %s; p1(%d) p2(%d)\n”, p1.equals(p2), p1.hashCode(), p2.hashCode());
// 比较p1 和 p4， 并打印它们的hashCode()
System.out.printf(“p1.equals(p4) : %s; p1(%d) p4(%d)\n”, p1.equals(p4), p1.hashCode(), p4.hashCode());
// 打印set
System.out.printf(“set:%s\n”, set);
}
/**
- @desc Person类。
*/
private static class Person {
int age;
String name;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String toString() {
return name + " - " +age;
}
/**
- @desc重写hashCode
*/
@Override
public int hashCode(){
int nameHash = name.toUpperCase().hashCode();
return nameHash ^ age;
}
/**
- @desc 覆盖equals方法
*/
@Override
public boolean equals(Object obj){
if(obj == null){
return false;
}
//如果是同一个对象返回true，反之返回false
if(this == obj){
return true;
}
//判断是否类型相同
if(this.getClass() != obj.getClass()){
return false;
}
Person person = (Person)obj;
return name.equals(person.name) && age==person.age;
}
}
}
运行结果：
p1.equals(p2) : true; p1(68545) p2(68545)
p1.equals(p4) : false; p1(68545) p4(68545)
set:[aaa - 200, eee - 100]
结果分析：
这下，equals()生效了，HashSet中没有重复元素。
比较p1和p2，我们发现：它们的hashCode()相等，通过equals()比较它们也返回true。所以，p1和p2被视为相等。
比较p1和p4，我们发现：虽然它们的hashCode()相等；但是，通过equals()比较它们返回false。所以，p1和p4被视为不相等。
原则
1.同一个对象（没有发生过修改）无论何时调用hashCode()得到的返回值必须一样。 如果一个key对象在put的时候调用hashCode()决定了存放的位置，而在get的时候调用hashCode()得到了不一样的返回值，这个值映射到了一个和原来不一样的地方，那么肯定就找不到原来那个键值对了。
**2.hashCode()的返回值相等的对象不一定相等，通过hashCode()和equals()必须能唯一确定一个对象。**不相等的对象的hashCode()的结果可以相等。hashCode()在注意关注碰撞问题的时候，也要关注生成速度问题，完美hash不现实。
**3.一旦重写了equals()函数（重写equals的时候还要注意要满足自反性、对称性、传递性、一致性），就必须重写hashCode()函数。**而且hashCode()的生成哈希值的依据应该是equals()中用来比较是否相等的字段。
如果两个由equals()规定相等的对象生成的hashCode不等，对于hashMap来说，他们很可能分别映射到不同位置，没有调用equals()比较是否相等的机会，两个实际上相等的对象可能被插入不同位置，出现错误。其他一些基于哈希方法的集合类可能也会有这个问题
4.说说Object类下面有几种方法呢？
====================
Object有几种方法呢？
Java语言是一种单继承结构语言，Java中所有的类都有一个共同的祖先。这个祖先就是Object类。
如果一个类没有用extends明确指出继承于某个类，那么它默认继承Object类。
Object的方法我们在平时基本都会用到，但如果没有准备被忽然这么一问，还是有点懵圈的。
分析
Object类是Java中所有类的基类。位于java.lang包中，一共有13个方法。如下图：
具体解答
1.Object()
这个没什么可说的，Object类的构造方法。(非重点)
2.registerNatives()
为了使JVM发现本机功能，他们被一定的方式命名。例如，对于
java.lang.Object.registerNatives，对应的C函数命名为Java_java_lang_Object_registerNatives。
通过使用registerNatives（或者更确切地说，JNI函数RegisterNatives），可以命名任何你想要你的C函数。(非重点)
3.clone()
clone()函数的用途是用来另存一个当前存在的对象。只有实现了Cloneable接口才可以调用该方法，否则抛出
CloneNotSupportedException异常。（注意：回答这里时可能会引出设计模式的提问）
4.getClass()
final方法，用于获得运行时的类型。该方法返回的是此Object对象的类对象/运行时类对象Class。效果与Object.class相同。（注意：回答这里时可能会引出类加载，反射等知识点的提问）
5.equals()
equals用来比较两个对象的内容是否相等。默认情况下(继承自Object类)，equals和是一样的，除非被覆写(override)了。（注意：这里可能引出更常问的“equals与的区别”及hashmap实现原理的提问）
6.hashCode()
该方法用来返回其所在对象的物理地址（哈希码值），常会和equals方法同时重写，确保相等的两个对象拥有相等的hashCode。（同样，可能引出hashmap实现原理的提问）
7.toString()
toString()方法返回该对象的字符串表示，这个方法没什么可说的。
8.wait()
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法。（引出线程通信及“wait和sleep的区别”的提问）
9.wait(long timeout)
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者超过指定的时间量。（引出线程通信及“wait和sleep的区别”的提问）
10.wait(long timeout, int nanos)
导致当前的线程等待，直到其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者其他某个线程中断当前线程，或者已超过某个实际时间量。（引出线程通信及“wait和sleep的区别”的提问）
11.notify()
唤醒在此对象监视器上等待的单个线程。（引出线程通信的提问）
12. notifyAll()
唤醒在此对象监视器上等待的所有线程。（引出线程通信的提问）
13.finalize()
当垃圾回收器确定不存在对该对象的更多引用时，由对象的垃圾回收器调用此方法。（非重点，但小心引出垃圾回收的提问）
5.Redis中是如何实现分布式锁的？
===================
分布式锁常见的三种实现方式：
-
数据库乐观锁；
-
基于Redis的分布式锁；
-
基于ZooKeeper的分布式锁。
本地面试考点是，你对Redis使用熟悉吗？Redis中是如何实现分布式锁的。
要点
Redis要实现分布式锁，以下条件应该得到满足
互斥性
- 在任意时刻，只有一个客户端能持有锁。
不能死锁
- 客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
容错性
- 只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。
实现
可以直接通过 set key value px milliseconds nx 命令实现加锁， 通过Lua脚本实现解锁。
//获取锁（unique_value可以是UUID等）
SET resource_name unique_value NX PX 30000
//释放锁（lua脚本中，一定要比较value，防止误解锁）
if redis.call(“get”,KEYS[1]) == ARGV[1] then
return redis.call(“del”,KEYS[1])
else
return 0
end
代码解释
-
set 命令要用 set key value px milliseconds nx，替代 setnx + expire 需要分两次执行命令的方式，保证了原子性，
-
value 要具有唯一性，可以使用UUID.randomUUID().toString()方法生成，用来标识这把锁是属于哪个请求加的，在解锁的时候就可以有依据；
-
释放锁时要验证 value 值，防止误解锁；
-
通过 Lua 脚本来避免 Check And Set 模型的并发问题，因为在释放锁的时候因为涉及到多个Redis操作 （利用了eval命令执行Lua脚本的原子性）；
加锁代码分析
首先，set()加入了NX参数，可以保证如果已有key存在，则函数不会调用成功，也就是只有一个客户端能持有锁，满足互斥性。其次，由于我们对锁设置了过期时间，即使锁的持有者后续发生崩溃而没有解锁，锁也会因为到了过期时间而自动解锁（即key被删除），不会发生死锁。最后，因为我们将value赋值为requestId，用来标识这把锁是属于哪个请求加的，那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。
解锁代码分析
将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。在执行的时候，首先会获取锁对应的value值，检查是否与requestId相等，如果相等则解锁（删除key）。
存在的风险
如果存储锁对应key的那个节点挂了的话，就可能存在丢失锁的风险，导致出现多个客户端持有锁的情况，这样就不能实现资源的独享了。
-
客户端A从master获取到锁
-
在master将锁同步到slave之前，master宕掉了（Redis的主从同步通常是异步的）。 主从切换，slave节点被晋级为master节点
-
客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。导致存在同一时刻存不止一个线程获取到锁的情况。
redlock算法出现
这个场景是假设有一个 redis cluster，有 5 个 redis master 实例。然后执行如下步骤获取一把锁：
-
获取当前时间戳，单位是毫秒；
-
跟上面类似，轮流尝试在每个 master 节点上创建锁，过期时间较短，一般就几十毫秒；
-
尝试在大多数节点上建立一个锁，比如 5 个节点就要求是 3 个节点 n / 2 + 1；
-
客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了；
-
要是锁建立失败了，那么就依次之前建立过的锁删除；
-
只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁。
Redisson实现
Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还实现了可重入锁（Reentrant Lock）、公平锁（Fair Lock、联锁（MultiLock）、 红锁（RedLock）、 读写锁（ReadWriteLock）等，还提供了许多分布式服务。
Redisson提供了使用Redis的最简单和最便捷的方法。Redisson的宗旨是促进使用者对Redis的关注分离（Separation of Concern），从而让使用者能够将精力更集中地放在处理业务逻辑上。
Redisson 分布式重入锁用法
Redisson 支持单点模式、主从模式、哨兵模式、集群模式，这里以单点模式为例：
// 1.构造redisson实现分布式锁必要的Config
Config config = new Config();
config.useSingleServer().setAddress(“redis://127.0.0.1:5379”).setPassword(“123456”).setDatabase(0);
// 2.构造RedissonClient
RedissonClient redissonClient = Redisson.create(config);
// 3.获取锁对象实例（无法保证是按线程的顺序获取到）
RLock rLock = redissonClient.getLock(lockKey);
try {
/**
-
4.尝试获取锁
-
waitTimeout 尝试获取锁的最大等待时间，超过这个值，则认为获取锁失败
-
leaseTime 锁的持有时间,超过这个时间锁会自动失效（值应设置为大于业务处理的时间，确保在锁有效期内业务能处理完）
*/
boolean res = rLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
if (res) {
//成功获得锁，在这里处理业务
}
} catch (Exception e) {
throw new RuntimeException(“aquire lock fail”);
}finally{
//无论如何, 最后都要解锁
rLock.unlock();
}
加锁流程图
解锁流程图
我们可以看到，RedissonLock是可重入的，并且考虑了失败重试，可以设置锁的最大等待时间， 在实现上也做了一些优化，减少了无效的锁申请，提升了资源的利用率。
需要特别注意的是，RedissonLock 同样没有解决 节点挂掉的时候，存在丢失锁的风险的问题。而现实情况是有一些场景无法容忍的，所以 Redisson 提供了实现了redlock算法的 RedissonRedLock，RedissonRedLock 真正解决了单点失败的问题，代价是需要额外的为 RedissonRedLock 搭建Redis环境。
所以，如果业务场景可以容忍这种小概率的错误，则推荐使用 RedissonLock， 如果无法容忍，则推荐使用 RedissonRedLock。
6.单例模式有几种写法？
============
“你知道茴香豆的‘茴’字有几种写法吗？”
纠结单例模式有几种写法有用吗？有点用，面试中经常选择其中一种或几种写法作为话头，考查设计模式和coding style的同时，还很容易扩展到其他问题。
这里讲解几种笔者常用的写法，但切忌生搬硬套，去记“茴香豆的写法”。编程最大的乐趣在于“know everything, control everything”。
JDK版本：oracle java 1.8.0_102
大体可分为4类，下面分别介绍他们的基本形式、变种及特点。
饱汉模式
饱汉是变种最多的单例模式。我们从饱汉出发，通过其变种逐渐了解实现单例模式时需要关注的问题。
基础的饱汉
饱汉，即已经吃饱，不着急再吃，饿的时候再吃。所以他就先不初始化单例，等第一次使用的时候再初始化，即“懒加载”。
// 饱汉
// UnThreadSafe
public class Singleton1 {
private static Singleton1 singleton = null;
private Singleton1() {
}
public static Singleton1 getInstance() {
if (singleton == null) {
singleton = new Singleton1();
}
return singleton;
}
}
饱汉模式的核心就是懒加载。好处是更启动速度快、节省资源，一直到实例被第一次访问，才需要初始化单例；小坏处是写起来麻烦，大坏处是线程不安全，if语句存在竞态条件。
写起来麻烦不是大问题，可读性好啊。因此，单线程环境下，基础饱汉是笔者最喜欢的写法。但多线程环境下，基础饱汉就彻底不可用了。下面的几种变种都在试图解决基础饱汉线程不安全的问题。
饱汉 - 变种 1
最粗暴的犯法是用synchronized关键字修饰getInstance()方法，这样能达到绝对的线程安全。
// 饱汉
// ThreadSafe
public class Singleton1_1 {
private static Singleton1_1 singleton = null;
private Singleton1_1() {
}
public synchronized static Singleton1_1 getInstance() {
if (singleton == null) {
singleton = new Singleton1_1();
}
return singleton;
}
}
变种1的好处是写起来简单，且绝对线程安全；坏处是并发性能极差，事实上完全退化到了串行。单例只需要初始化一次，但就算初始化以后，synchronized的锁也无法避开，从而getInstance()完全变成了串行操作。性能不敏感的场景建议使用。
饱汉 - 变种 2
变种2是“臭名昭著”的DCL 1.0。
针对变种1中单例初始化后锁仍然无法避开的问题，变种2在变种1的外层又套了一层check，加上synchronized内层的check，即所谓“双重检查锁”（Double Check Lock，简称DCL）。
// 饱汉
// UnThreadSafe
public class Singleton1_2 {
private static Singleton1_2 singleton = null;
public int f1 = 1; // 触发部分初始化问题
public int f2 = 2;
private Singleton1_2() {
}
public static Singleton1_2 getInstance() {
// may get half object
if (singleton == null) {
synchronized (Singleton1_2.class) {
if (singleton == null) {
singleton = new Singleton1_2();
}
}
}
return singleton;
}
}
变种2的核心是DCL，看起来变种2似乎已经达到了理想的效果：懒加载+线程安全。可惜的是，正如注释中所说，DCL仍然是线程不安全的，由于指令重排序，你可能会得到“半个对象”，即”部分初始化“问题。
饱汉 - 变种 3
变种3专门针对变种2，可谓DCL 2.0。
针对变种3的“半个对象”问题，变种3在instance上增加了volatile关键字，原理见上述参考。
// 饱汉
// ThreadSafe
public class Singleton1_3 {
private static volatile Singleton1_3 singleton = null;
public int f1 = 1; // 触发部分初始化问题
public int f2 = 2;
private Singleton1_3() {
}
public static Singleton1_3 getInstance() {
if (singleton == null) {
synchronized (Singleton1_3.class) {
// must be a complete instance
if (singleton == null) {
singleton = new Singleton1_3();
}
}
}
return singleton;
}
}
多线程环境下，变种3更适用于性能敏感的场景。但后面我们将了解到，就算是线程安全的，还有一些办法能破坏单例。
当然，还有很多方式，能通过与volatile类似的方式防止部分初始化。读者可自行阅读内存屏障相关内容，但面试时不建议主动装B。
饿汉模式
与饱汉相对，饿汉很饿，只想着尽早吃到。所以他就在最早的时机，即类加载时初始化单例，以后访问时直接返回即可。
// 饿汉
// ThreadSafe
public class Singleton2 {
private static final Singleton2 singleton = new Singleton2();
private Singleton2() {
}
public static Singleton2 getInstance() {
return singleton;
}
}
饿汉的好处是天生的线程安全（得益于类加载机制），写起来超级简单，使用时没有延迟；坏处是有可能造成资源浪费（如果类加载后就一直不使用单例的话）。
值得注意的时，单线程环境下，饿汉与饱汉在性能上没什么差别；但多线程环境下，由于饱汉需要加锁，饿汉的性能反而更优。
Holder模式
我们既希望利用饿汉模式中静态变量的方便和线程安全；又希望通过懒加载规避资源浪费。Holder模式满足了这两点要求：核心仍然是静态变量，足够方便和线程安全；通过静态的Holder类持有真正实例，间接实现了懒加载。
// Holder模式
// ThreadSafe
public class Singleton3 {
private static class SingletonHolder {
private static final Singleton3 singleton = new Singleton3();
private SingletonHolder() {
}
}
private Singleton3() {
}
/**
- 勘误：多写了个synchronized。。
public synchronized static Singleton3 getInstance() {
return SingletonHolder.singleton;
}
*/
public static Singleton3 getInstance() {
return SingletonHolder.singleton;
}
}
相对于饿汉模式，Holder模式仅增加了一个静态内部类的成本，与饱汉的变种3效果相当（略优），都是比较受欢迎的实现方式。同样建议考虑。
枚举模式
用枚举实现单例模式，相当好用，但可读性是不存在的。
基础的枚举
将枚举的静态成员变量作为单例的实例：
// 枚举
// ThreadSafe
public enum Singleton4 {
SINGLETON;
}
代码量比饿汉模式更少。但用户只能直接访问实例Singleton4.SINGLETON——事实上，这样的访问方式作为单例使用也是恰当的，只是牺牲了静态工厂方法的优点，如无法实现懒加载。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
总结
一般像这样的大企业都有好几轮面试，所以自己一定要花点时间去收集整理一下公司的背景，公司的企业文化，俗话说「知己知彼百战不殆」，不要盲目的去面试，还有很多人关心怎么去跟HR谈薪资。
这边给大家一个建议，如果你的理想薪资是30K，你完全可以跟HR谈33~35K，而不是一下子就把自己的底牌暴露了出来，不过肯定不能说的这么直接，比如原来你的公司是25K，你可以跟HR讲原来的薪资是多少，你们这边能给到我的是多少？你说我这边希望可以有一个20%涨薪。
最后再说几句关于招聘平台的，总之，简历投递给公司之前，请确认下这家公司到底咋样，先去百度了解下，别被坑了，每个平台都有一些居心不良的广告党等着你上钩，千万别上当！！！
Java架构学习资料，学习技术内容包含有：Spring，Dubbo，MyBatis, RPC, 源码分析，高并发、高性能、分布式,性能优化，微服务 高级架构开发等等。
还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书。
024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。**
[外链图片转存中…(img-S5FuBsN9-1711695394282)]
[外链图片转存中…(img-SOSjace7-1711695394282)]
[外链图片转存中…(img-XSLHDmox-1711695394283)]
[外链图片转存中…(img-d7Gqf4Pl-1711695394283)]
[外链图片转存中…(img-S0zvIFUz-1711695394283)]
[外链图片转存中…(img-fMTxqhds-1711695394284)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-v2BBfm3Z-1711695394284)]
总结
一般像这样的大企业都有好几轮面试，所以自己一定要花点时间去收集整理一下公司的背景，公司的企业文化，俗话说「知己知彼百战不殆」，不要盲目的去面试，还有很多人关心怎么去跟HR谈薪资。
这边给大家一个建议，如果你的理想薪资是30K，你完全可以跟HR谈33~35K，而不是一下子就把自己的底牌暴露了出来，不过肯定不能说的这么直接，比如原来你的公司是25K，你可以跟HR讲原来的薪资是多少，你们这边能给到我的是多少？你说我这边希望可以有一个20%涨薪。
最后再说几句关于招聘平台的，总之，简历投递给公司之前，请确认下这家公司到底咋样，先去百度了解下，别被坑了，每个平台都有一些居心不良的广告党等着你上钩，千万别上当！！！
Java架构学习资料，学习技术内容包含有：Spring，Dubbo，MyBatis, RPC, 源码分析，高并发、高性能、分布式,性能优化，微服务 高级架构开发等等。
还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书。
[外链图片转存中…(img-VgnEMNrk-1711695394285)]
476
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
