• 嗨!《MineBBS 2022年度总结》新鲜出炉啦!快来看看我们今年做得怎么样吧~【点我去看】
  • 高速简洁的Minecraft下载页来啦!快来体验一下吧~【点我传送】

Java 我的世界java开发者在线回答问题,把java编程遇到问题发到下方,我会尽快回答

六氟化氙

【 Lv: 1 】
Nov 29, 2022
28
2
17h 45m
1,470金粒
0钻石
我是java开发者,有sun公司认证,我的世界红石服务器tis管理员,我的世界红石协会会员,我的世界计分板初稿编辑者,我的世界16位计算机参与者
 

小关

《我的世界》小游戏服务器 PixelMC
Staff member
Mar 30, 2019
57
29
1d 4h 33m
Awards
2
1,299金粒
0钻石
由于主题内容与您所选的主题前缀“资源”不符,故已将您的主题前缀改为“Java”,希望您以后注意相关操作!
 
  • Like
Reactions: 六氟化氙

超神的冰凉

【 Lv: 4 】
开发者
组长
Apr 20, 2019
505
1
347
3d 11h 40m
Awards
9
41,997金粒
21钻石
PowerNukkitX项目有一个很久没有解决的性能问题,希望大佬能帮忙指点一二:
PNX服务端中具有一个事件派发系统,一旦某个事件发生,就会将注册了的监听器对象中的特定方法一一调用,但是调用事件监听器的开销相对于直接内联方法调用而言大不少,所以我们十分迫切地希望能够对它进行优化,请问您有相关思路吗?
最开始,我们通过反射获取方法对象并通过反射invoke调用用哈希表注册的监听器,但是反射的开销是直接内联调用的几十倍。后来开发组编写了一个内嵌的专用编译器,将事件系统中所有的反射调用都编译成lambda调用(invokeVirtual或invokeDynamic)然后注入JVM中。目前遇到的性能问题就在这里:小部分编码不良的插件频繁地注册和取消监听器类,这导致我们需要频繁地对AppClassLoader中的类表进行注册和取消,而这个过程中由于JVM的类保存机制,很多完全没用的类会挤压在堆上的元空间中,导致内存浪费;而且,加载一个新的lambda时,我们即便确认生成的字节码没有问题,JVM仍然会进行开销高昂的类验证,这也导致了开服速度有一定下降。有什么好的方法来避免这一点呢?感谢
 

xiaobao4909

【 Lv: 3 】
Aug 27, 2021
150
12
3d 8h 26m
Awards
2
1,516金粒
0钻石
您好 我认为您可以去帮助Geyser成员完成他们的工作 让他们的翻译移动变的香草化 他们还尚未解决 互通服的希望就交给您了 您去帮助Geyser解决问题吧!
GeyserGithub: https://github.com/GeyserMC/Geyser
 
  • Like
Reactions: Zaiton_

六氟化氙

【 Lv: 1 】
Nov 29, 2022
28
2
17h 45m
1,470金粒
0钻石
PowerNukkitX项目有一个很久没有解决的性能问题,希望大佬能帮忙指点一二:
PNX服务端中具有一个事件派发系统,一旦某个事件发生,就会将注册了的监听器对象中的特定方法一一调用,但是调用事件监听器的开销相对于直接内联方法调用而言大不少,所以我们十分迫切地希望能够对它进行优化,请问您有相关思路吗?
最开始,我们通过反射获取方法对象并通过反射invoke调用用哈希表注册的监听器,但是反射的开销是直接内联调用的几十倍。后来开发组编写了一个内嵌的专用编译器,将事件系统中所有的反射调用都编译成lambda调用(invokeVirtual或invokeDynamic)然后注入JVM中。目前遇到的性能问题就在这里:小部分编码不良的插件频繁地注册和取消监听器类,这导致我们需要频繁地对AppClassLoader中的类表进行注册和取消,而这个过程中由于JVM的类保存机制,很多完全没用的类会挤压在堆上的元空间中,导致内存浪费;而且,加载一个新的lambda时,我们即便确认生成的字节码没有问题,JVM仍然会进行开销高昂的类验证,这也导致了开服速度有一定下降。有什么好的方法来避免这一点呢?感谢
好的稍等我想想
 

六氟化氙

【 Lv: 1 】
Nov 29, 2022
28
2
17h 45m
1,470金粒
0钻石
PowerNukkitX项目有一个很久没有解决的性能问题,希望大佬能帮忙指点一二:
PNX服务端中具有一个事件派发系统,一旦某个事件发生,就会将注册了的监听器对象中的特定方法一一调用,但是调用事件监听器的开销相对于直接内联方法调用而言大不少,所以我们十分迫切地希望能够对它进行优化,请问您有相关思路吗?
最开始,我们通过反射获取方法对象并通过反射invoke调用用哈希表注册的监听器,但是反射的开销是直接内联调用的几十倍。后来开发组编写了一个内嵌的专用编译器,将事件系统中所有的反射调用都编译成lambda调用(invokeVirtual或invokeDynamic)然后注入JVM中。目前遇到的性能问题就在这里:小部分编码不良的插件频繁地注册和取消监听器类,这导致我们需要频繁地对AppClassLoader中的类表进行注册和取消,而这个过程中由于JVM的类保存机制,很多完全没用的类会挤压在堆上的元空间中,导致内存浪费;而且,加载一个新的lambda时,我们即便确认生成的字节码没有问题,JVM仍然会进行开销高昂的类验证,这也导致了开服速度有一定下降。有什么好的方法来避免这
好的,我现在正在编写一个基础监听器,灵敏性高,内存较多,开销较少
 

六氟化氙

【 Lv: 1 】
Nov 29, 2022
28
2
17h 45m
1,470金粒
0钻石
PowerNukkitX项目有一个很久没有解决的性能问题,希望大佬能帮忙指点一二:
PNX服务端中具有一个事件派发系统,一旦某个事件发生,就会将注册了的监听器对象中的特定方法一一调用,但是调用事件监听器的开销相对于直接内联方法调用而言大不少,所以我们十分迫切地希望能够对它进行优化,请问您有相关思路吗?
最开始,我们通过反射获取方法对象并通过反射invoke调用用哈希表注册的监听器,但是反射的开销是直接内联调用的几十倍。后来开发组编写了一个内嵌的专用编译器,将事件系统中所有的反射调用都编译成lambda调用(invokeVirtual或invokeDynamic)然后注入JVM中。目前遇到的性能问题就在这里:小部分编码不良的插件频繁地注册和取消监听器类,这导致我们需要频繁地对AppClassLoader中的类表进行注册和取消,而这个过程中由于JVM的类保存机制,很多完全没用的类会挤压在堆上的元空间中,导致内存浪费;而且,加载一个新的lambda时,我们即便确认生成的字节码没有问题,JVM仍然会进行开销高昂的类验证,这也导致了开服速度有一定下降。有什么好的方法来避免这一点呢?感谢
开发前端原代码:
package org.apollodevs.helloworld.commands;

import org.apollodevs.helloworld.Main;

public class helloComand implements CommandExecutor{

Suppres sWarnings("unused")
private main plugin;

public helloCommand(Main plugin) {
this.plugin - plugin;
plugin.getCommand("hello").setExecutor(this);
}
player p - (player) sender;

if (p.hasPermission("hello.use)) {
p.sendMessage("hil");
return yure;
}else {
p.sendMessage("you do not have permission to execute thos command!");
}
return false;
}
}
 

超神的冰凉

【 Lv: 4 】
开发者
组长
Apr 20, 2019
505
1
347
3d 11h 40m
Awards
9
41,997金粒
21钻石
开发前端原代码:
package org.apollodevs.helloworld.commands;

import org.apollodevs.helloworld.Main;

public class helloComand implements CommandExecutor{

Suppres sWarnings("unused")
private main plugin;

public helloCommand(Main plugin) {
this.plugin - plugin;
plugin.getCommand("hello").setExecutor(this);
}
player p - (player) sender;

if (p.hasPermission("hello.use)) {
p.sendMessage("hil");
return yure;
}else {
p.sendMessage("you do not have permission to execute thos command!");
}
return false;
}
}
但我无法看出这跟我的问题有什么关系。
 
  • Like
Reactions: mc的小腐竹

xiaobao4909

【 Lv: 3 】
Aug 27, 2021
150
12
3d 8h 26m
Awards
2
1,516金粒
0钻石
具体问题大概是 Geyser开发组无法做到准确翻译BE玩家的移动 导致BE玩家在移动的时候会造成反作弊误判 因为反作弊认为他不是正常香草的移动轨迹 希望您能解决此问题 这是困扰了Geyser开发组多次的问题 感谢解决!
 

八重豆子

PVEP | 麦联
VIP
Feb 11, 2022
26
7
1d 16h 47m
861金粒
0钻石
看您的帖子让我原本枯燥的日常生活充满了乐趣:开森:
谢谢你,java大神(doge)
 

Zaiton_

【 Lv: 3 】
开发者
Jul 7, 2021
70
8
2d 3h 21m
Awards
1
3,480金粒
0钻石
怎么不说话了大佬🥺🥺
能不能把作品链接和你在tis服务器的截图提供一下🥺🥺
想膜拜大佬
 

fireanmeng

【 Lv: 1 】
Jan 9, 2023
2
0
4h 21m
321金粒
0钻石
开发前端原代码:
package org.apollodevs.helloworld.commands;

import org.apollodevs.helloworld.Main;

public class helloComand implements CommandExecutor{

Suppres sWarnings("unused")
private main plugin;

public helloCommand(Main plugin) {
this.plugin - plugin;
plugin.getCommand("hello").setExecutor(this);
}
player p - (player) sender;

if (p.hasPermission("hello.use)) {
p.sendMessage("hil");
return yure;
}else {
p.sendMessage("you do not have permission to execute thos command!");
}
return false;
}
}
几个问题:
这段代码里的Suppres明显不是java关键字 结合上下文应改为@SuppressWarnings("unused")
return yure; 很显然java里没有个东西叫yure,应该是true 如果你在main里定义了一个叫yure的玩意 当我没说
java是个大小写敏感的语言 你import的是Main为什么下面声明变量类型的时候变成了main 这样类型根本不匹配
player p - (player) sender -应该是=。另一个this.plugin - plugin;同理。
"hello.use这一段会导致你下面的一切全部被当做字符串处理 应该是"hello.use"。
最离谱的:helloCommand这个方法下面的所有调用 不属于任何一个方法 丢进编译器里立马爆炸
提示文本里的一堆错词我就不说了。
这位的其他问题我基本上不会,但是类验证……试试-noverify(雾)
 

Ruok

【 Lv: 4 】
开发者
Jun 30, 2018
315
4
125
6d 22h 17m
Awards
10
ruok.cc
1,466金粒
30钻石
几个问题:
这段代码里的Suppres明显不是java关键字 结合上下文应改为@SuppressWarnings("unused")
return yure; 很显然java里没有个东西叫yure,应该是true 如果你在main里定义了一个叫yure的玩意 当我没说
java是个大小写敏感的语言 你import的是Main为什么下面声明变量类型的时候变成了main 这样类型根本不匹配
player p - (player) sender -应该是=。另一个this.plugin - plugin;同理。
"hello.use这一段会导致你下面的一切全部被当做字符串处理 应该是"hello.use"。
最离谱的:helloCommand这个方法下面的所有调用 不属于任何一个方法 丢进编译器里立马爆炸
提示文本里的一堆错词我就不说了。
这位的其他问题我基本上不会,但是类验证……试试-noverify(雾)
这明显是不知道在哪抄的图片转文字
 

雷糍小雾

【 Lv: 1 】
Jan 18, 2023
26
8
11h 11m
1,150金粒
0钻石
蛙趣,我最开始以为哪位jvav大佬在这里帮助编程新手回答问题:喷水:,谢谢您,jvav大🐍(doge)