关于jvm初始化阶段的接口初始化问题

深入理解jvm第2版中写明“一个接口在初始化时,并不要求其父接口全部都完成了初始化,只有在真正使用到父接口的时候(如引用接口中定义的常量)才会初始化”,但是前文又有说,final修饰的常量在编译阶段会存入调用类的常量池中,实际上并没有直接引用定义常量的类,因此不会出发定义常量的类的初始化,而接口中都是由static final修饰的常量,引用接口中定义的常量会初始化不就和这条矛盾了吗?有什么可以说明“一个接口初始化,其父接口没有初始化”的例子吗?noob求各位jvm大佬指教!😥😥😥

#Java#
全部评论
public class MyTest6 { public static String printWhenInit(String s){ System.out.println(s); return s.substring(s.indexOf(" ")); } public static void main(String[] args){ System.out.println(SubI.iField3); //静态的运行时才能确定的常量,这时存有该常量的接口被初始化,其父类不会被初始化 // System.out.println(SubI.iField2); //静态的编译器可以确定的常量,这时三个接口都不会被初始化,原因和类一样 } } interface SuperI { public static final String superField = MyTest6.printWhenInit(" initializing SuperI.superField "); } interface I extends SuperI{ public static final String iField = MyTest6.printWhenInit("initializing I.iField "); public static final String iField2 = "heihie"; public static final String iField3 = UUID.randomUUID().toString(); } interface SubI extends I { public static final String subField = MyTest6.printWhenInit(" initializing SubI.subField "); } 你运行下这个就看到了,打印了initializing I.iField说明I初始化了,但是没打印initializing SuperI.superField说明父接口没有初始化
点赞 回复 分享
发布于 2019-07-17 19:05
SuperI.class Compiled from "SuperI.java" public interface SuperI {   public static final java.lang.String superField;   static {};     Code:        0: ldc           #1                  // String  initializing SuperI.superField        2: invokestatic  #2                  // Method Main.printWhenInit:(Ljava/lang/String;)Ljava/lang/String;        5: putstatic     #3                  // Field superField:Ljava/lang/String;        8: return } I.class Compiled from "I.java" public interface I extends SuperI {   public static final java.lang.String iField;   public static final java.lang.String iField2;   static {};     Code:        0: ldc           #1                  // String initializing I.iField        2: invokestatic  #2                  // Method Main.printWhenInit:(Ljava/lang/String;)Ljava/lang/String;        5: putstatic     #3                  // Field iField:Ljava/lang/String;        8: return } SubI.class Compiled from "SubI.java" public interface SubI extends I {   public static final java.lang.String subField;   static {};     Code:        0: ldc           #1                  // String  initializing SubI.subField        2: invokestatic  #2                  // Method Main.printWhenInit:(Ljava/lang/String;)Ljava/lang/String;        5: putstatic     #3                  // Field subField:Ljava/lang/String;        8: return } static {}就是<clinit>方法,环境是JDK 1.8,可见3个接口都初始化了
点赞 回复 分享
发布于 2019-07-17 18:48
public class MyTest6 { public static String printWhenInit(String s){ System.out.println(s); return s.substring(s.indexOf(" ")); } public static void main(String[] args){ System.out.println(SubI.iField); //静态的运行时才能确定的常量,这时存有该常量的接口被初始化,其父类不会被初始化 // System.out.println(SubI.iField2); //静态的编译器可以确定的常量,这时三个接口都不会被初始化,原因和类一样 } } interface SuperI { public static final String superField = MyTest6.printWhenInit(" initializing SuperI.superField "); } interface I extends SuperI{ public static final String iField = MyTest6.printWhenInit("initializing I.iField "); public static final String iField2 = "heihie"; } interface SubI extends I { public static final String subField = MyTest6.printWhenInit(" initializing SubI.subField "); } 执行main就能验证子接口I初始化了而父接口SuperI没有初始化(因为如果SuperI初始化了的话会打印initializing SuperI.superField)
点赞 回复 分享
发布于 2019-07-17 18:07
static final修饰的常量分为两种 一种是在编译器能够确定的比如public static final String iField2 = "heihie";这种常量在编译期会放进常量池中,当使用到该常量时不会触发类的初始化 第二种是只有在运行期能够确定的比如public static final String uuid = UUID.randomUUID().toString();这种常量不运行是肯定不知道他的值的,所以在编译期也不可能放进常量池中(值都不知道还怎么放进去),当使用到该常量时会发出类的初始化。 然后你提问的第一句话一个接口在初始化时,并不要求其父接口全部都完成了初始化,只有在真正使用到父接口的时候(如引用接口中定义的常量)才会初始化这里的常量指上面的第二种。第二句话final修饰的常量在编译阶段会存入调用类的常量池中,实际上并没有直接引用定义常量的类,因此不会出发定义常量的类的初始化这里的常量指的是上面的第一种。
点赞 回复 分享
发布于 2019-07-17 17:03
被static final修饰的不一定是常量
点赞 回复 分享
发布于 2019-07-17 16:48

相关推荐

最终还是婉拒了小红书的offer,厚着脸皮回了字节。其实这次字节不管是组内的氛围、HR的沟通体验,都比之前好太多,开的薪资也还算过得去,这些都是让我下定决心的原因之一。但最核心的,还是抵不住对Agent的兴趣,选择了Ai&nbsp;Coding这么一个方向。因为很多大佬讲过,在未来比较火的还是属于那些更加垂类的Agent,而Ai&nbsp;Coding恰好是Coding&nbsp;Agent这么一个领域,本质上还是程序员群体和泛程序员群体这个圈子的。目前也已经在提前实习,也是全栈这么一个岗位。就像最近阿里P10针对前端后端等等不再那么区分,确实在Agent方向不太区分这个。尤其是我们自己做AI&nbsp;Coding的内容,基本上90%左右的内容都是AI生成的,AI代码仓库贡献率也是我们的指标之一。有人说他不好用,那肯定是用的姿态不太对。基本上用对Skill、Rules&nbsp;加上比较好的大模型基本都能Cover你的大部分需求,更别说Claude、Cursor这种目前看来Top水准的Coding工具了(叠甲:起码在我看来是这样)。所以不太区分的主要原因,还是针对一些例如Claude&nbsp;Code、Cursor、Trae、Codex、CC等一大堆,他们有很多新的概念和架构提出,我们往往需要快速验证(MVP版本)来看效果。而全栈就是这么快速验证的一个手段,加上Ai&nbsp;Coding的辅助,目前看起来问题不大(仅仅针对Agent而言)。而且Coding的产品形态往往是一个Plugin、Cli之类的,本质还是属于大前端领域。不过针对业务后端来看,区分还是有必要的。大家很多人也说Agent不就是Prompt提示词工程么?是的没错,本质上还是提示词。不过现在也衍生出一个新的Context&nbsp;Eneering,抽象成一种架构思想(类比框架、或者你们业务架构,参考商品有商品发布架构来提效)。本质还是提示词,但是就是能否最大化利用整个上下文窗口来提升效果,这个还是有很多探索空间和玩法的,例如Cursor的思想:上下文万物皆文件,&nbsp;CoWork之类的。后续也有一些Ralph&nbsp;Loop啥的,还有Coding里面的Coding&nbsp;Act姿态。这种才是比较核心的点,而不是你让AI生成的那提示词,然后调用了一下大模型那么简单;也不是dify、LangGraph搭建了一套workflow,从一个node走到另外一个node那么简单。Agent和WorkFLow还是两回事,大部分人也没能很好的区分这一点。不过很多人说AI泡沫啥啥啥的,我们ld也常把这句话挂在嘴边:“说AI泡沫还是太大了”诸如此类。我觉得在AI的时代,懂一点还是会好一点,所以润去字节了。目前的实习生活呢,除了修一些Tools的问题,还包括对比Claude、Cursor、Trae在某些源码实现思想上的点,看看能不能迁移过来,感觉还是比较有意思。不过目前组内还是主要Follow比较多,希望下一个阶段就做一些更有创新的事情哈哈。这就是一个牛马大学生的最终牧场,希望能好好的吧。说不定下次发的时候,正式AI泡沫结束,然后我又回归传统后端这么一个结局了。欢迎交流👏,有不对的🙅不要骂博主(浅薄的认知),可以私聊交流
码农索隆:和优秀的人,做有挑战的事
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务