【巩固Java基础】抽象,rabbitmq和kafka的区别面试

接口的默认方法

格式:public default 返回值类型 方法名(参数列表){方法体}

说明:default关键字不能省略

作用:默认方法可以解决接口升级问题 ☆

应用场景:比如一个接口,被10个类实现,那么当此接口需要功能升级,也就是要新添加一个抽象方法,这时候,所有之前实现过此接口的类,全部都会报错,牵一发而动全身。如何解决这个问题呢?答:不添加抽象方法,而是添加默认方法 ☆ 默认方法添加完以后,可以在实例化实现类的时候,进行调用(相当于继承过来了 ☆)

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

注意事项:☆

接口的默认方法,可以通过实现类对象直接调用

接口的默认方法,也可以被接口的实现类进行覆盖重写 @Override(不能加default关键字了 ☆)

接口的静态方法

格式:public static 返回值类型 方法名(参数列表){方法体}

在这里插入图片描述

使用:接口名.静态方法名(参数列表);

在这里插入图片描述

注意:静态方法不能用接口实现类对象调用,必须使用接口名调用(不同于类中静态方法)

说明:一个类可以实现多个接口,如果多个接口中的静态方法名字相同,对象调用就会冲突 ☆

接口的成员变量

说明:接口中可以定义成员变量,但是必须使用public static final三个关键字来修饰 ☆

final关键字:表示最终的(含义是之后不能修改了)

结论:public static final从效果上看,这其实就是接口中的常量了(常量:不变的量)

格式:

在这里插入图片描述

注意事项:

①可以省略public static final,但是注意,不写也照样是这仨玩意

接口中的常量,必须赋值,不可以不赋值 ☆(没有默认值,不同于类中的成员变量)

③接口中的常量名称,建议完全大写,且用下划线分隔

接口总结

接口不能有静态代码块,且不能写构造方法

②一个类可以同时实现多个接口,但父类只能有一个:即“单继承、多实现”☆

③继承和实现连写:public class MyInterfaceImpl extends Demo2 implements MyInterfaceA,MyInterfaceB{ … }

④实现类习惯写成以Impl结尾的形式 ☆

⑤如果实现类所实现的多个接口中,存在有重复的抽象方法,那么只需要覆盖重写一次即可

如果实现类所实现的多个接口中,存在有重复的默认方法,那么必须对重复的默认方法重写(不考虑静态方法)

​ **这种情况重写默认方法后 就不能调用到接口中的默认方法 **

⑦如果实现类没有覆盖重写所有接口中的抽象方法,那么此类必须是抽象类

一个类如果 【直接父类 】当中的方法,和接口中的默认方法产生了冲突,优先使用父类当中的方法 ☆

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

结论:继承父类优先于接口实现 ☆

⑨类与类之间是单继承;类与接口之间是多实现;接口与接口之间可以多继承extends(不考虑)

多个父接口中的抽象方法可以重复,多个父接口中的默认方法如果重复,子接口必须进行重写

关于java多态

明确概念:多态的含义就是多种形态 ☆

说明:多态性说的是对象,不是类**(对象具有多态性 ☆)**

说明:继承(extends)或实现(implements)是多态性的前提 ☆

案例:小明是一个学生,同时也是一个人,小明是一个对象,这个对象,既有学生的形态,也有人的形态。

结论:一个对象拥有多种形态,这就是对象的多态性 ☆

多态性实质:代码中体现出的多态性,其实就是一句话:【父类引用指向子类对象】☆

多态性格式:左父右子【两种格式】

父类名称 对象名 = new 子类名称();

接口名称 对象名 = new 实现类名称();

代码①:动物与猫的案例 ☆(一只猫,当做动物看,没毛病)

在这里插入图片描述

代码②:USB与U盘的案例

在这里插入图片描述

多态形式的访问:☆

①多态情况访问成员变量:☆

直接通过对象名称访问成员变量:(看等号左边是谁,就优先用谁,没有,则向上寻找)

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

间接通过成员方法访问成员变量:(看该方法属于谁,就优先使用谁,没有,则向上寻找)

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

重要结论:多态情况,子类方法如果没有重写父类,则访问父类;子类方法如果重写了父类方法,则访问子类 ☆

②多态情况访问成员方法:☆(父子类都有,优先用子类)

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

多态的好处:☆

结论:推荐多态写法 ☆

在这里插入图片描述

场景分析:如果是方法的参数,需求是接收每个子类对象都可以,那么此时需要用多态写法,否则就要方法重载 ☆

好处:等号左边都是父类(或接口),此时等号右边无论new谁,都可以赋值给父类(或接口),使代码更灵活 ☆

关于对象的转型:☆

①对象的向上转型:(多态写法)

格式:父类 对象名 = new 子类名();

例如:Animal obj = new Cat();

小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级Java工程师,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
img
img
img

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Java)
img

总结

虽然面试套路众多,但对于技术面试来说,主要还是考察一个人的技术能力和沟通能力。不同类型的面试官根据自身的理解问的问题也不尽相同,没有规律可循。

上面提到的关于这些JAVA基础、三大框架、项目经验、并发编程、JVM及调优、网络、设计模式、spring+mybatis源码解读、Mysql调优、分布式监控、消息队列、分布式存储等等面试题笔记及资料

有些面试官喜欢问自己擅长的问题,比如在实际编程中遇到的或者他自己一直在琢磨的这方面的问题,还有些面试官,尤其是大厂的比如 BAT 的面试官喜欢问面试者认为自己擅长的,然后通过提问的方式深挖细节,刨根到底。

面试来说,主要还是考察一个人的技术能力和沟通能力。不同类型的面试官根据自身的理解问的问题也不尽相同,没有规律可循。

[外链图片转存中…(img-RRgLenbY-1710745888453)]

[外链图片转存中…(img-2rsSx9IB-1710745888453)]

上面提到的关于这些JAVA基础、三大框架、项目经验、并发编程、JVM及调优、网络、设计模式、spring+mybatis源码解读、Mysql调优、分布式监控、消息队列、分布式存储等等面试题笔记及资料

有些面试官喜欢问自己擅长的问题,比如在实际编程中遇到的或者他自己一直在琢磨的这方面的问题,还有些面试官,尤其是大厂的比如 BAT 的面试官喜欢问面试者认为自己擅长的,然后通过提问的方式深挖细节,刨根到底。

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

  • 18
    点赞
  • 28
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: RabbitMQKafka 有以下主要区别: 1. 架构:RabbitMQ 是一个消息代理,而 Kafka 是一个分布式流平台。 2. 实现:RabbitMQ 基于队列模型,Kafka 基于发布/订阅模型。 3. 吞吐量:Kafka 的吞吐量更高,因为它具有分布式架构。 4. 持久性:Kafka 消息存储更长,因为它使用分布式文件系统。 5. 可靠性:RabbitMQ 提供更高的可靠性,因为它支持事务和可靠性投递。 6. 用途:RabbitMQ 适用于异步通信和任务队列,Kafka 适用于大规模数据处理和实时流数据。 ### 回答2: RabbitMQKafka是目前流行的消息中间件,常常被用于分布式系统中的异步通信。下面我将从以下几方面来回答这道面试题目:消息模型、消息顺序、消息传输、消息可靠性、性能以及社区支持。 1. 消息模型 RabbitMQ采用标准的AMQP协议,支持消息的持久化,消息可靠性较高,可以设置队列的过期时间、消息优先级和消息路由规则等。RabbitMQ的代码实现和架构较为简单,适合实现任务队列、分发、RPC等场景。 而Kafka采用发布-订阅模式,支持消息的批量处理和异步处理,能够高效地处理大量数据流,适用于高吞吐量的场景,如日志收集、实时计算等。 2. 消息顺序 RabbitMQ采用FIFO(先进先出)模式,保证消息的顺序。但是在分布式环境下,当消息被多个消费者同时消费时,队列的顺序可能会被打乱。 而Kafka采用分区机制,支持多个订阅者对同一分区进行消费,并保证消息顺序,因此在分布式环境下,Kafka消息的顺序更可靠。 3. 消息传输 RabbitMQ消息传输采用AMQP协议,需要建立TCP连接,较为重量级。而Kafka采用Zero-copy技术,消息传输速度更快。 4. 消息可靠性 RabbitMQ可以通过消息持久化、消息确认等机制来保证消息的可靠性,但在高并发场景下容易出现消息堆积、阻塞的情况。 Kafka采用副本机制,将每个分区的数据副本分布到多个Broker上,避免了单点故障,保证了高可靠性。 5. 性能 Kafka的性能优于RabbitMQ,尤其是在海量数据处理场景下,Kafka的吞吐量甚至可以达到百万级别。 6. 社区支持 RabbitMQ社区较为活跃,拥有大量的插件和扩展,同时也有较为完善的文档和支持。而Kafka的社区也很活跃,特别是在大数据领域得到了广泛应用。 综上所述,RabbitMQKafka都是优秀的消息中间件,具体使用还需根据业务场景和需求来决定。对于需要高吞吐量和海量数据处理的场景,可以选择Kafka。对于需要保证消息可靠性和队列顺序的场景,可以选择RabbitMQ。总之,在选择中间件时需要考虑到多个方面的因素,并综合评估各种可能的解决方案。 ### 回答3: RabbitMQKafka都是流行的消息队列系统,用于支持分布式应用程序之间的异步通信。它们都能够高效地处理海量的数据流和消息传递,从而在不同的应用场景之间提供了更好的可伸缩性和可靠性。然而,它们之间也有一些明显的区别,这些区别需要根据具体的业务需求来进行选择。 第一,RabbitMQ是基于AMQP协议的,而Kafka是基于发布-订阅模型的消息传递系统。因此,RabbitMQ更适合于复杂的消息传递场景,例如要求消息队列能够支持事务等高级特性的场景,同时它提供了集群化的高可用性,支持消息的持久化和可靠性传递;而Kafka更适合于实时数据流处理的场景,例如日志收集、实时分析和数据管理,因为它的架构采用了多副本备份的方式来保证数据的可靠性,并提供了更高的吞吐量和较低的延迟。 第二,RabbitMQ为了防止消息阻塞,采用了预取机制,也就是在向自己注册消费者时,可以通过设置prefetch参数来控制每次消费的消息数目;而Kafka没有这种预取机制,因为它把消息传递设计为一种持续的流,因此能够更好地处理实时数据流。 第三,RabbitMQ消费者在没有消息时会处于空闲状态,不会占用系统资源;而Kafka消费者在没有消息时会花费更多的CPU和内存资源,因为它在内部轮询消息,而不是确定性地等待消息的到来。此时如果没有消息,就会不断地轮询,浪费系统资源。 第四,RabbitMQ支持消息的推送和拉取两种模式,而Kafka只支持拉取模式。如果应用程序需要及时地获取外部数据,那么可以考虑使用RabbitMQ的推送模式,但如果需要大量处理海量数据,可以选择Kafka的拉取模式,因为它可以在不受限制地一次性获取大量数据。 综上所述,RabbitMQKafka都有各自的优点和应用场景,选择合适的消息队列系统需要根据具体的业务需求来进行调整选择。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值