Oracle包级变量天然会话级持久化，无需手动维护；其值在会话生命周期内保持，仅当会话断开才重置；初始化段（BEGIN…END）确保每次包首次调用时可靠初始化，但不可调用本包其他过程。
包级变量天然就是会话级的，不需要额外“维护”
Oracle 包里的 g_call_count 这类包级变量，默认就在会话生命周期内持久存在。只要没断开会话（哪怕应用层重连但复用连接池），这个值就不会重置。这不是靠你手动“维护”出来的行为，而是 Oracle 的运行时机制决定的 —— 它把整个包加载进 PGA（进程全局区）后，变量就驻留在那里了。
初始化段（Initialization Section）必须显式写在包体末尾
很多人以为包级变量声明时赋初值（比如 g_counter NUMBER := 0）就够了，其实这仅在包首次加载时生效；但如果包被 ALTER PACKAGE ... COMPILE 重新编译过，或者会话中触发了隐式重载（如依赖对象变更），变量可能保留旧值或变成 NULL —— 行为不可控。
真正可靠的方式是把初始化逻辑放在包体的 BEGIN ... END; 初始化段里：
CREATE OR REPLACE PACKAGE BODY session_stats AS
FUNCTION get_calls RETURN NUMBER IS
BEGIN
RETURN g_call_count;
END;
<p>PROCEDURE increment IS
BEGIN
g_call_count := g_call_count + 1;
END;</p><p>BEGIN -- ← 这个 BEGIN 是初始化段起点
g_call_count := 0; -- 每次包首次被访问时执行一次
END session_stats;- 该段只在当前会话中，该包第一次被调用（任意过程/函数）时执行一次
- 即使包体被重新编译，下次调用时仍会重新触发初始化段
- 不能在里面调用本包其他过程（会报 PLS-00306：wrong number/type of arguments）
别把包变量当全局缓存用，小心状态污染
包变量不是跨会话共享的，但容易误以为“所有用户都看到同一个值”。实际上每个会话各自一份副本 —— 这是优点也是陷阱：
- 多个 Web 请求复用同一个数据库连接（如连接池未配置
validateConnectionOnBorrow），它们会共用同一份包变量，导致计数错乱、缓存脏读 - 包变量无法被事务回滚：你在事务中修改了
g_cache，然后ROLLBACK，变量值不会恢复 - 调试困难：你用 SQL Developer 手动执行
session_stats.increment，和应用代码里调用它，其实是两个不同会话的变量，彼此不干扰也不互通
真正提升共享效率的关键不在变量，而在包加载机制
包的性能优势主要来自 Oracle 的内存加载策略，而不是你存了多少变量：
- 包头+包体首次调用时整体加载进 SGA 共享池，后续调用直接走内存，省去反复解析和磁盘读取
- 但如果你在包里大量使用动态 SQL 或频繁打开游标却不关闭，反而会撑爆 PGA，抵消掉加载优势
- 若真需要跨会话共享数据（比如配置热更新），得用
DBMS_SHARED_POOL.KEEP配合表或上下文（DBMS_SESSION.SET_CONTEXT），而不是依赖包变量
最常被忽略的一点：包变量的“高效”只对单一会话内多次调用有意义；一旦涉及连接池、多线程或长连接复用，它的行为边界就变得模糊——这时候你得先确认你的应用到底有没有真正隔离会话。
