10.28 JAVA 继承-重载-重写

本文详细解读Java中的继承机制,介绍如何通过extends实现单继承和多重继承特性。着重讲解重写(Override)规则,包括方法参数、返回类型和访问权限的要求,并区分重写与重载的区别,讨论了重载的条件。

一. 继承

继承就是子类继承父类的特征和行为,使得子类对象(实例)具有父类的实例域和方法,或者子类继承父类的方法,使得子类具有父类的相同行为。

Java中通过extends关键字声明A类从B类继承(class A extends class B)。

Java 不支持多继承,但支持多重继承。

子类拥有父类的非private的属性和方法。

子类可以对父类扩展。

子类可以用自己的方式实现父类的方法。

extends单继承 ,implements可以具有多继承的特性。

super:对父类成员访问,引用当前对象父类。

this:指向自己的引用。

final关键字声明类不可以继承。

子类不继承父类构造器,只能调用。

如果父类的构造器带有参数,子类的构造器必须显式用super调用父类构造器配以适当的参数列表。

如果父类构造器没有参数,则子类构造器不需要使用super调用,系统会自动调用父类无参构造器。

二.重写(Override)

子类对父类的的可访问的方法的实现过程重新编写,返回值形参不能变。也就是说子类根据需要实现父类的方法。

class A{

public void eat(){

System.out.println("A吃");

}

}

class B extends A{

public void eat(){

System.out.println("B吃");

}

public void play(){

System.out.println("B玩耍");

}

}

public class  Test(){

public static void main(String[] args){

A a = new A();   //A对象实例化

A b = new B();   //B对象实例化

a.eat();    //调用A类方法

b.eat();     //调用B类方法

b.play();    //出现编译错误,b的引用类型A类没有play方法。

}

}

重写的规则:

1.参数列表必须完全相同。

2.返回类型与被重写的可以不同,但必须由父类的返回值派生出来。

3.访问的权限不能比父类被重写的方法的访问权限低。

4.父类成员方法只能被子类重写。

5.final声明的方法不能被重写。static声明的方法不能被重写,但能被重新声明。

6.子类父类处于同一包中,子类可重写父类所有方法,除了final和private的声明的方法。

7.子类和父类不处于同一包中,子类只能重写父类由public 和protected声明的非final方法。

8.重写不能抛出新异常。

9.构造方法不能被重写。

10.只有继承一个类才能重写此类。

三.重载(Overload)

重载只能处于一个类,方法相同,参数不同,返回类型可同可不同。

被重载的方法必须更改参数列表(参数个数或类型)

被重载的方法可以更改返回类型

被重载的方法可以更改访问修饰符

被重载的方法可以声明新的异常

谢谢你的火焰图信息!你贴出的部分火焰图数据非常清晰,我们来逐层解读它,并回答你最初的问题: --- ### ✅ 你贴出的火焰图结构如下: ``` 96.99% 0.00% 0 test_server libpthread-2.27.so [.] start_thread | ---start_thread | |--96.12%--worker_thread | |--54.14%--__strcmp_sse2_unaligned | |--26.69%--compute_all_shortest_paths | |--10.28%--broadcast_routing ``` --- ### 🧐 这张图说明了什么? #### 🔹 `worker_thread` 占用了 96.12% 的 CPU 时间(Children 列) - 表示整个调用栈中,这个线程是热点。 #### 🔹 `__strcmp_sse2_unaligned` 占了 54.14% - 说明整个线程中,有 **超过一半的时间在做字符串比较**。 #### 🔹 `compute_all_shortest_paths` 占了 26.69% - 表示路径计算函数本身耗时,但它内部又调用了 `strcmp`。 #### 🔹 `broadcast_routing` 占了 10.28% - 路由广播部分,相对较少。 --- ### ❓你问的是:“这三个函数在同一行”? 实际上,在火焰图中: - `worker_thread` 是主调函数; - 它调用了 `compute_all_shortest_paths`; - 后者又调用了 `__strcmp_sse2_unaligned`; - 同时还有 `broadcast_routing` 独立调用。 它们并不是“在同一行”,而是**共享同一个调用栈层级**,表示: ``` start_thread └── worker_thread ├── __strcmp_sse2_unaligned ├── compute_all_shortest_paths └── broadcast_routing ``` --- ### ❓那是不是 `compute_all_shortest_paths` 返回值导致拷贝问题? **不是。** - 从火焰图来看,`compute_all_shortest_paths` 本身只占 26.69%,但它的内部逻辑却导致了 54.14% 的 `strcmp`; - 所以瓶颈在 `compute_all_shortest_paths` 内部频繁调用了 `strcmp`,**而不是返回值拷贝问题**。 --- ### ✅ 结论 - `compute_all_shortest_paths` 函数内部存在大量字符串比较; - 这些比较导致了 `__strcmp_sse2_unaligned` 成为性能热点; - `worker_thread` 是主调函数,所以它“看起来”耗时最多; - 你真正需要优化的是 `compute_all_shortest_paths` 及其使用的图结构。 --- ### ✅ 建议优化方向 #### ✅ 1. 将图节点名从字符串改为整数 ID 例如: ```c typedef struct { int node_id; // 替代原来的 char* 或 string // 其他字段... } Node; ``` #### ✅ 2. 使用哈希表映射字符串到整数 ID ```c std::unordered_map<std::string, int> node_name_to_id; ``` #### ✅ 3. 用 `std::unordered_map<int, ...>` 替代 `std::map<std::string, ...>` 减少红黑树查找时的字符串比较。 #### ✅ 4. 使用 `perf annotate` 精确定位热点指令 ```bash perf annotate compute_all_shortest_paths ``` 查看具体哪一行代码调用了 `strcmp`。 --- ### ✅ 总结 - 你看到的火焰图结构是调用栈关系,不是“同一行”的问题; - 性能瓶颈在 `compute_all_shortest_paths` 内部的字符串比较; - 优化图结构的设计,改用整数 ID 是关键。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值