Java hello world 确实就要占用 30M

最近看了几个帖子都是说 java 内存的，自己也写 java ，还从来没关注过一个 hello world, 今天一时兴起测试了下，确实需要占用 30 。

测试方法和代码如下：

public class Main {
    public static void main(String[] args) throws InterruptedException {
        System.out.println("hello memory 02");
        Thread.sleep(60 * 60 * 1000);
    }
}

方式 1：直接运行 java Main.java 。70M 内存

方式 2：先编译，再运行： javac Main.java, 然后 java Main. 30M 内存

方式 3 编译成 jar 包在运行，java -jar main.jar 30M 内存。编译的 maven 配置如下

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.example</groupId>
    <artifactId>untitled</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>21</maven.compiler.source>
        <maven.compiler.target>21</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>
                <version>3.2.1</version>
                <configuration>
                    <createDependencyReducedPom>false</createDependencyReducedPom>
                </configuration>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>shade</goal>
                        </goals>
                        <configuration>
                            <transformers>
                                <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                                    <mainClass>Main</mainClass>
                                </transformer>
                            </transformers>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

</project>

以上的 java 运行环境：

openjdk version "21.0.3" 2024-04-16 LTS
OpenJDK Runtime Environment Temurin-21.0.3+9 (build 21.0.3+9-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.3+9 (build 21.0.3+9-LTS, mixed mode, sharing)

如果觉得上面哪里测试有问题的，欢迎来拍。

一句话总结：Java 内存没救了，在意内存别用 Java 。

shuimugan

63 天前

@haython 任何的重构肯定能降低资源，因为已经熟悉了原来的业务逻辑。但是用 java8 重构肯定不能节省 3/4 ，因为 java8 的并发模型就摆在那里。
这个视频是我打游戏的时候挂着听的，有几个重点指标：
1.资源占用少，原来那个 java 服务冷启动 100 秒，能吃满一个核，高峰期 java8 服务挂掉后重启那一刻猛猛吃 cpu ，在 k8s 里属于自己搞死自己；
2.碰到了那种等慢 sql 结果搞到线程池满的 case ，就会死，迁移到.net 的异步 IO 真香。这点其实非常的重要，现实的业务逻辑到处都是等待 IO ，java8 那个线程模型就是不行；
3.分布式事务也有很好的支持；
4.迁移成本很低，几乎 0 感，这个在带团队上非常重要；

sagaxu

63 天前

@zzhaolei x86 计算型 c7 ，2c4g ，100mbps ，一年是八万零四百三十二？

以 X86 2C 计算型为例，4g 包年是 1730 ，8g 包年是 2466 ，16g 包年是 2810
你那配置网费是大头，不会有人蠢到每台服务器都买一份公网带宽吧。

我用 3 台 16 核 16G 的服务器，扛过日请求 10 亿到 50 亿的业务，同样的业务换 Go 重写撑死也就变成 3 台 8G 的(假设有 16 核 8G 的型号卖)，一年也就能省个万儿八千，网费一年 20 万，抠这万把块钱好像意义不大。要是有个上百服务器，倒是能考虑要不要抠一抠。

@shuimugan 重构过程本身就会优化设计，即使是用 Java8 重写一下都能省不少资源。

shuimugan

63 天前

聊这些肯定要结合历史发展，高速增长的业务本来就是以扩张为主，加上.net core 是 2016 年中才发布的 1.0 ，之前.net framework 生态都是闭源的，肯定是市场上什么人多就招什么人，有资本的注入，招人和服务器那点费用对比业务增长的收益不值一提。

java8 当然不止有线程模型，但是其它的并发模型都是一堆坑，写起来就是掉进回调地狱的，有点技术广度了解过其它语言的并发模型都不会选。为了保证业务扩张，肯定是以其它公司踩过坑的稳定方案为主。

但是在业务放缓，经济下行之后，之前欠下的债都是要还的，预算变少了，砍人还是砍服务器，总得选一个。

在国内，换领导肯定是影响技术选型的重大因素。net8 虽然发布比 java21 晚，但是.net core 1.0 从发布到.net 8 重大变更很少，倒是兼容性和效能上不断改进，该踩的坑都踩得差不多了，反倒是 java21 在生态位是缺失的，不敢用很正常。
@haython
@sagaxu