核心是操作主体非acl所有者导致权限异常；需确保principal实例与初始化所有者完全一致，调用addowner()注册所有者，并在敏感操作前用isowner()校验，避免lastownerexception。
这个异常的核心是：你正用一个非所有者的身份，去执行只有acl所有者才能做的操作，比如添加、删除权限条目或修改所有者关系。解决的关键不是绕过检查，而是让操作主体真正具备所有者身份，或确保操作前已通过身份校验。
确认并使用正确的所有者身份
ACL对象创建后，必须显式设置合法所有者，且后续敏感操作必须由该所有者发起。不能靠“猜测”或硬编码用户名——要确保Principal实例与ACL初始化时指定的所有者完全一致（包括类类型和内容）。
- 创建ACL时，传入明确的、可复用的
Principal对象，例如：new PrincipalImpl("admin") - 执行
addEntry、deleteEntry或removeOwner前，先调用acl.isOwner(principal)验证 - 避免在不同作用域中新建同名但不同实例的
Principal，它们在Java中不等价
确保所有者已在ACL中注册
仅把Principal传给AclImpl构造函数并不足够。必须调用acl.addOwner(principal)，否则即使构造时指定了所有者，ACL内部仍可能不认可其所有权。
- 典型初始化顺序：
Acl acl = new AclImpl(owner); acl.addOwner(owner); - 如果使用自定义
Principal实现，需确保equals()和hashCode()正确重写，否则isOwner判断会失败 - 调试时可打印
acl.getOwners()结果，确认所有者列表非空且包含预期对象
避免跨用户误操作的代码习惯
不要让普通用户凭空构造Principal去调用ACL方法。应将ACL管理封装在受控服务中，由服务统一验证身份后再代理操作。
- 例如：提供
grantPermission(Principal owner, Principal target, Permission perm)方法，内部先校验owner是否为ACL所有者 - 拒绝直接暴露
Acl实例给不可信调用方；对外只暴露经过权限过滤的操作接口 - 在多线程环境下，注意ACL实现是否线程安全；如非线程安全，需加同步控制
注意LastOwnerException的连带风险
当你尝试移除所有者时，若当前只剩唯一所有者，会触发LastOwnerException。这不是NotOwnerException，但常伴随出现——因为开发者在修复前者时可能粗暴删所有者，却忘了ACL至少要留一个管理者。
- 执行
removeOwner前，先检查acl.getOwners().asList().size() > 1 - 如需更换所有者，应先
addOwner(newOwner)，再removeOwner(oldOwner) - 避免在未确认ACL状态的情况下批量清理所有者
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
