在Java Card中（我对Classic downto 2.1.1感兴趣），applet所需的瞬态（RAM）通常由makeTransientByteArray()安装。该方法接受参数CLEAR_ON_RESET或CLEAR_ON_DESELECT。后来发出警告
只有当创建对象的applet与当前选定的applet位于同一上下文中时，才能访问
CLEAR_ON_DESELECT个临时对象。如果当前选定的applet与创建对象的applet不在同一上下文中，则访问
CLEAR_ON_DESELECT瞬态对象时，Java Card运行时环境将抛出SecurityException。
我的阅读是CLEAR_ON_DESELECT（但不是CLEAR_ON_RESET）允许运行时覆盖两个小程序之间的瞬态（如上所述在安装时分配），只要它们不同时被选中，因此，分配 m j 字节的几个applet将消耗大约max（ m j ）瞬态字节，而不是总和（米 <子>Ĵ）。
更新：我已经告诉了一些调整，至少在某些运行时环境中，覆盖有选择地针对从不同包分配的瞬态。但我没有找到参考，也没有找到这种规则/机制的准确描述。
问题：这个覆盖机制是否有时在运行时实现？如果是的话，它什么时候发生？是否有运行时而不是实现它的卡？如果是的话，有没有办法通过实验来讲述，可能来自广告中的Java Card版本？
其他问题：准确地说，“上下文”在引用的限制中意味着什么？特别是，applet的另一个实例可以使用CLEAR_ON_DESELECT瞬态，与由here显示的机制分配的实例共享它？注意：我不想分享瞬态内容，只是为了避免两次分配，以解决运行时可能缺少覆盖的问题。
更新：我问了同样的问题here并得到了一个有趣的答案。
答案 0 :(得分：1)
没有直接的理由让Oracle指定CLEAR_ON_DESELECT可用于在不同的applet实例之间共享内存，但如果不允许这样做，那将是一个非常奇怪的实现。
如果在任何地方指定，可能是Oracle为实施Java Card的公司提供的测试工具。实际上，Oracle根本没有指定实际的底层内存模型，如果需要，可以由实现来实现。对齐数据。 Java Card字节码＆amp;必须支持CAP文件格式，但这与底层实现有关。
关于上下文，来自VM规范：
在上下文和包之间存在一对一的映射 小程序已定义。一种思考上下文的简单方法就是 运行时等效于包，因为Java包是编译时的 构造并且在运行时没有直接表示。作为一个 结果，来自同一个包的所有applet实例将共享 相同的背景。
请注意，这并不意味着如果以任何方式取消选择applet，则不会清除CLEAR_ON_DESELECT数组。这只是访问条件。我将不得不找出，但我想如果同一个上下文中的另一个applet使用该数组，它将只能看到零字节。
但关于CLEAR_ON_DESELECT和上下文的这一部分就是我阅读规范的方式。