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;</p>
- 该段只在当前会话中,该包第一次被调用(任意过程/函数)时执行一次
- 即使包体被重新编译,下次调用时仍会重新触发初始化段
- 不能在里面调用本包其他过程(会报 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),而不是依赖包变量
最常被忽略的一点:包变量的“高效”只对单一会话内多次调用有意义;一旦涉及连接池、多线程或长连接复用,它的行为边界就变得模糊——这时候你得先确认你的应用到底有没有真正隔离会话。











