1. 理解protected修饰符的本质
在Java的访问控制体系中，protected修饰符处于public和private之间的微妙位置。它不像public那样完全开放，也不像private那样彻底封闭，而是为继承体系设计了一种"有限度的共享"机制。protected成员可以被同一包内的其他类访问，也可以被不同包中的子类访问，这种设计体现了面向对象中"家族特权"的思想。
关键理解：protected打破了包边界的限制，但仅对"血亲"（子类）开放特权。这种设计在框架开发中尤为重要，比如Spring框架内部就大量使用protected方法供子类扩展。
从JVM层面看，protected访问控制是在编译期通过访问标志位(access_flags)实现的。当类成员被声明为protected时，编译器会在.class文件中标记ACC_PROTECTED标志。JVM在解析符号引用时会检查：
- 访问者是否与当前类在同一个包
- 如果不是同包，则检查是否是当前类的子类
只有满足以上任一条件才能通过访问验证
2. protected的具体访问规则解析
2.1 同包访问权限
在同一包内，protected成员的可见性与默认(package-private)访问级别完全一致。这意味着：
java复制// 包com.example
public class Parent {
protected String familySecret = "Protect this";
}
class Neighbor { // 同包类
void peek() {
Parent p = new Parent();
System.out.println(p.familySecret); // 可以访问
}
}
这种设计使得包内协作变得便利，但同时也要求开发者对包内类的可信度有充分把握。在大型项目中，如果滥用protected导致包内耦合度过高，会显著降低代码的可维护性。
2.2 跨包子类访问
protected最核心的特性体现在跨包继承时的访问规则：
java复制// 包com.another
import com.example.Parent;
public class Child extends Parent {
void reveal() {
System.out.println(familySecret); // 可以访问继承的protected成员
Parent p = new Parent();
// System.out.println(p.familySecret); // 编译错误！非常容易混淆的点
}
}
这里存在一个关键但常被误解的规则：子类可以通过继承访问protected成员，但不能通过父类实例访问。这是因为：
- 通过继承访问时，成员属于子类自身
- 通过实例访问时，相当于访问"别人的"protected成员
2.3 与其它修饰符的对比
通过下表可以清晰看出protected在访问控制体系中的定位：
| 修饰符 | 类内部 | 同包类 | 不同包子类 | 不同包非子类 |
|---|---|---|---|---|
| private | ✓ | ✗ | ✗ | ✗ |
| 默认 | ✓ | ✓ | ✗ | ✗ |
| protected | ✓ | ✓ | ✓ | ✗ |
| public | ✓ | ✓ | ✓ | ✓ |
3. protected的典型应用场景
3.1 模板方法模式实现
protected在模板方法模式中扮演关键角色。父类定义算法骨架，将可变部分声明为protected方法供子类定制：
java复制public abstract class GameAI {
// 公开的模板方法
public final void playTurn() {
collectResources();
buildStructures();
buildUnits();
}
// protected方法供子类实现
protected abstract void buildStructures();
protected abstract void buildUnits();
private void collectResources() {
// 通用实现...
}
}
这种设计既保证了算法结构的稳定性，又提供了足够的扩展灵活性。Spring框架中的AbstractApplicationContext就大量使用这种模式。
3.2 框架中的扩展点设计
现代框架通常通过protected方法暴露扩展点：
java复制// 在Spring Framework中的典型应用
public abstract class AbstractBeanFactory {
protected Object createBean(String name, RootBeanDefinition mbd) {
// 复杂的创建逻辑...
}
protected void applyPropertyValues(String name, Object bean,
BeanDefinition mbd) {
// 属性注入逻辑...
}
}
这种设计允许框架使用者通过继承来定制特定行为，同时避免暴露不必要的内部细节。在Android开发中，Activity的生命周期方法（如onCreate）也是protected的，体现了相同的设计哲学。
3.3 单元测试中的妙用
在测试领域，protected可以优雅地解决测试代码访问被测类内部状态的问题：
java复制// 生产代码
public class OrderService {
protected ValidationResult validateOrder(Order order) {
// 复杂的验证逻辑...
}
}
// 测试代码
public class OrderServiceTest {
@Test
void testValidation() {
TestableOrderService service = new TestableOrderService();
ValidationResult result = service.validateTestOrder(testOrder);
// 断言验证结果...
}
private static class TestableOrderService extends OrderService {
// 通过继承暴露protected方法给测试
ValidationResult validateTestOrder(Order order) {
return super.validateOrder(order);
}
}
}
相比使用反射或修改为public，这种方式既满足了测试需求，又保持了生产代码的封装性。
4. protected使用中的陷阱与最佳实践
4.1 常见误区警示
-
实例访问误解：
java复制// 错误认知：认为可以通过父类实例访问protected成员 public class Child extends Parent { void method(Parent p) { System.out.println(p.familySecret); // 编译错误 } } -
构造方法误用：
java复制public class Parent { protected Parent() {} // 可能导致子类必须与父类同包 } -
接口中的无效声明：
java复制public interface MyInterface { protected void method(); // 编译错误：接口方法不能是protected }
4.2 设计原则建议
-
最小暴露原则：优先考虑默认(package-private)访问级别，仅在确实需要子类访问时才使用protected
-
文档配套原则：所有protected成员都应该有详细的文档说明，包括：
- 为什么需要protected访问级别
- 预期的覆盖或使用方式
- 调用时机和前置条件
-
稳定性承诺：protected成员实际上构成了对子类的API承诺，修改它们可能导致广泛的破坏
4.3 性能考量
从JVM角度看，不同访问级别的调用在性能上没有差异。现代JVM会通过内联优化消除方法调用的开销。protected方法调用与普通虚方法调用采用相同的invokevirtual指令：
code复制aload_0
invokevirtual #5 // Method familySecret:()Ljava/lang/String;
真正的性能考量应该放在设计层面：
- 过度使用protected会导致类之间耦合度升高
- 大量可覆盖方法会影响JVM的内联优化决策
5. 深入语言规范：protected的边界情况
5.1 不同包中的子类访问
当子类与父类位于不同包时，访问规则变得微妙：
java复制// 包com.library.core
public class Base {
protected int value;
}
// 包com.application
public class Derived extends Base {
void access(Base base) {
System.out.println(value); // 允许：访问继承的字段
// System.out.println(base.value); // 禁止：通过实例访问
}
}
这种设计确保了继承关系中的访问权限，同时防止了通过父类引用随意访问protected成员。
5.2 与匿名类的交互
匿名类访问外围类的protected成员时，行为可能出人意料：
java复制public class Outer {
protected int x;
void method() {
Runnable r = new Runnable() {
@Override public void run() {
System.out.println(x); // 可以访问
}
};
}
}
这是因为匿名类会被编译成外围类的嵌套类，共享相同的包作用域。但在不同包中继承时，情况会发生变化。
5.3 模块系统下的变化
Java 9引入的模块系统对protected访问产生了额外限制。即使满足继承关系，如果父类所在的包未导出给子类模块，protected访问也会失败：
code复制module com.library {
exports com.library.core; // 必须显式导出包含protected成员的包
}
这种变化要求库作者更谨慎地设计protected API，并明确声明哪些包允许被继承。
6. 真实项目中的经验分享
在开发企业级权限管理系统时，我们曾设计过这样的继承体系：
java复制// 框架核心包
public abstract class AbstractPermissionChecker {
protected final PermissionCache cache;
protected AbstractPermissionChecker(PermissionCache cache) {
this.cache = cache;
}
protected boolean checkPermission(User user, String resource) {
// 基础检查逻辑...
}
}
// 业务实现包
public class OrderPermissionChecker extends AbstractPermissionChecker {
@Override
public boolean canAccessOrder(User user, Order order) {
if (!checkPermission(user, "ORDER_ACCESS")) {
return false;
}
// 业务特定检查...
}
// 可以访问protected的cache字段
public void clearCache() {
cache.clear();
}
}
这个设计带来了几个好处：
- 强制业务实现类通过构造器注入依赖
- 保护核心权限检查逻辑不被破坏
- 允许业务类根据需要扩展或复用基础功能
遇到的坑点包括：
- 最初将cache字段设为private，导致业务类无法实现特定缓存策略
- 过度使用protected方法导致子类间出现意外的相互依赖
- 没有及时清理不再需要的protected方法，造成维护负担
经过迭代优化，我们总结出protected使用的"三要三不要"原则：
- 要为真正的扩展点使用protected
- 要对protected成员进行充分测试
- 要及时重构不再需要的protected成员
- 不要用protected暴露实现细节
- 不要为测试便利滥用protected
- 不要让protected方法签名频繁变更