变量具有不同的生命周期，而它们应该具有相同的生命周期答案

【问题标题】：Variables have different lifetimes, when they should have the same变量具有不同的生命周期，而它们应该具有相同的生命周期
【发布时间】：2015-05-27 14:49:46
【问题描述】：

为了学习 Rust，我正在编写一个 library 包装 JNI。我遇到了很多终生问题，并勇敢地与编译器抗争以解决它们，但有了这个我就放弃了。这就是问题所在。

现在，JNI 是 Java 虚拟机的接口，因此每个 Java 对象都必须绑定到 VM。为了做到这一点，我创建了“VM 指针”类型的 JavaVM，它主要是指针的包装器和创建 JavaEnv 对象的接口，它们只是 JNIEnv* 的包装器，同时也是更安全接口的提供者大多数 JNI 方法。

为了声明 JavaEnv 对象与 VM 相关联，我执行了以下操作：

pub struct JavaEnv<'a> {
    phantom: PhantomData<&'a JavaVM>,
    ...
}

现在，如果我理解正确，所有 JavaEnv 对象都将在生命周期内绑定到某个 JavaVM 对象，并且不会超过它，这正是我想要的。

JavaEnv -- 是一个用于操作 java 对象（和其他一些东西）的接口。现在，所有类型的 JNI 对象都实现了一个 trait：

pub trait JObject<'a>: Drop {
    fn get_env(&self) -> &'a JavaEnv<'a>;
    ...
}

他们自己都长这样：

pub struct JavaObject<'a> {
    env: &'a JavaEnv<'a>,
    ...
}

pub struct JavaClass<'a> {
    env: &'a JavaEnv<'a>,
    ...
}

现在，如果我再次理解正确，所有 JavaObject-s 都将在生命周期内绑定到某个 JavaEnv 对象，而该对象又绑定到 JavaVM 对象。

最后，Java 是具有默认引用语义的语言，所以对象比较只是一个浅层的引用比较，我想在 Rust 接口中体现它：

impl<'a, R: 'a + JObject<'a>> PartialEq<R> for JavaObject<'a> {
    fn eq(&self, other: &R) -> bool {
        self.get_env().is_same_object(self, other)
    }
}

impl<'a, R: 'a + JObject<'a>> PartialEq<R> for JavaClass<'a> {
    fn eq(&self, other: &R) -> bool {
        self.get_env().is_same_object(self, other)
    }
}

pub fn JavaEnv::is_same_object<T1: 'a + JObject<'a>, T2: 'a + JObject<'a>>(&self, obj1: &T1, obj2: &T2) -> bool {
    unsafe {
        ((**self.ptr).IsSameObject)(self.ptr, obj1.get_obj(), obj2.get_obj()) == JNI_TRUE
    }
}

这不起作用。这是一个测试：

let (cls, cap) = JavaClass::find(&env, "java/lang/String", cap).unwrap();
let (obj /*of class java/lang/String*/, cap) = cls.alloc(cap).unwrap();
let cls1 /*also java/lang/String*/ = obj.get_class(&cap);
assert!(cls1 == cls); 
let (sobj /*also of java/lang/String*/, cap) = JavaString::new(&env, "hi!", cap).unwrap();
assert!(cls1 != sobj);
let scls /*also java/lang/String*/ = sobj.get_class(&cap);
assert!(scls == cls1);
assert!(scls == cls);
// TODO: somehow these cls1, scls and cls have different lifetimes (or not?)
// So those two asserts do not compile!!
assert!(cls1 == scls);
assert!(cls == scls);

要“解决”这个问题，我必须更改 eq 代码：

impl<'a, 'b, R: 'b + JObject<'b>> PartialEq<R> for JavaObject<'a> {
    fn eq(&self, other: &R) -> bool {
        self.get_env().is_same_object(self, other)
    }
}

impl<'a, 'b, R: 'b + JObject<'b>> PartialEq<R> for JavaClass<'a> {
    fn eq(&self, other: &R) -> bool {
        self.get_env().is_same_object(self, other)
    }
}

pub fn JavaEnv::is_same_object<'b, T1: 'a + JObject<'a>, T2: 'b + JObject<'b>>(&self, obj1: &T1, obj2: &T2) -> bool {
    unsafe {
        ((**self.ptr).IsSameObject)(self.ptr, obj1.get_obj(), obj2.get_obj()) == JNI_TRUE
    }
}

但我不想比较附加到不同 VM 的 JObject！而且，甚至更多：我只是不明白，这些对象如何最终具有不同的生命周期参数？它们都是从同一个 JavaEnv 获得的，因此也是同一个 JavaVM！

所以，问题是：我做错了什么，为什么会发生这种情况以及如何解决这个问题？

【问题讨论】：

除了最后两个之外的所有断言都编译是真的吗？
很难深入研究这一点，因为您只提供了部分实现（考虑到复杂性，这是可以理解的）。不确定这会有所帮助，但是：get_class() 是否会返回一些终生的东西 'a ？或者，也许您可以考虑如下注释：T1: 'aa + JObject<'a>, T2: 'bb + JObject<'b> 并指定 where 'a: 'aa, 'b: 'bb? （: 表示“寿命延长”）
这里我认为 JVM 使用单例模式，您可以使用 getjvm 或其他东西从任何地方获取它。粗略的谷歌搜索似乎支持这一点：database.developer-works.com/article/15552998/…
@delnan，是的，这是真的。
@ArtemGr，这就是我提供代码链接的原因：它并没有那么大和复杂。 fn get_class(&'a self, _cap: &Capability) -> JavaClass<'a>; 到处通过代码我将“从 JavaEnv 到子对象的生命周期”传递给子对象。

标签： rust

【解决方案1】：

我相信你的基本前提有问题。查看此示例代码：

fn are_equal<'a>(a: &'a u8, b: &'a u8) -> bool {
    *a == *b
}

fn main() {
    let a = 42;

    {
        let b = 84;
        println!("{}", are_equal(&a, &b));
    }
}

这里，我们有一个方法，它接受两个引用参数和生命周期参数'a。但是，您可以清楚地看到 a 和 b（在 main 中）的实际生命周期不一样 - 由于块结束，a 的寿命比 b 长。

所需要的只是一些生命周期可以统一这两个参数，并且有 - 内部块的范围。这并不意味着整个生命周期必须完全相等。

【讨论】：