diagnostics 最近的时间轴更新
diagnostics

diagnostics

V2EX 第 616362 号会员,加入于 2023-02-28 15:00:25 +08:00
今日活跃度排名 1110
有多少人还在用 Maven 构建项目?
Java  •  diagnostics  •  9 天前  •  最后回复来自 ychost
127
出 desk mini x300+5600g+32G=1600
二手交易  •  diagnostics  •  110 天前  •  最后回复来自 popguy
15
微信真牛逼,视频加了 AI 识别
微信  •  diagnostics  •  167 天前  •  最后回复来自 lesismal
20
安卓/一加 ACE2 半年体验
Android  •  diagnostics  •  190 天前  •  最后回复来自 wy315700
37
深圳出 91 健康度 iPhone 13 蓝色 128g
二手交易  •  diagnostics  •  232 天前  •  最后回复来自 ArleneCheung
3
Air 不上 M3 是因为散热不够了吗?
Apple  •  diagnostics  •  261 天前  •  最后回复来自 Binlabs
27
安卓杀后台这么严重吗?高德导航都没法导完全?
  •  1   
    Android  •  diagnostics  •  313 天前  •  最后回复来自 diagnostics
    105
    diagnostics 最近回复了
    1 天前
    回复了 shtzlwdmkf 创建的主题 生活 有没有人跟我一样,婚后消费观不一样了
    @sagaxu 未必是开发商花,卖地的是谁呀?
    1 天前
    回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
    咱也不知道你用的是什么高阶 Node ~

    83 67 root S 263m 1% 2 0% node main.js
    67 0 root S 1704 0% 12 0% /bin/sh
    103 0 root S 1672 0% 11 0% /bin/sh
    109 103 root R 1596 0% 12 0% top
    /app/website # node -v
    v18.18.2
    /app/website # cat /proc/version
    Linux version 5.4.0-122-generic (buildd@lcy02-amd64-095) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022
    /app/website # cat /etc/issue
    Welcome to Alpine Linux 3.18
    Kernel \r on an \m (\l)

    ------------------------------------------------------------

    27095 root 20 0 12152 3332 2736 S 0.0 0.0 0:00.02 bash
    27129 root 20 0 2529768 23272 15708 S 0.0 0.1 0:00.16 java
    27169 root 20 0 48432 3712 3132 R 0.0 0.0 0:00.00 top

    [root@xxxx /]# java -version
    openjdk version "1.8.0_232"
    OpenJDK Runtime Environment (Zulu 8.42.0.23-linux64)-Microsoft-Azure-restricted (build 1.8.0_232-b18)
    OpenJDK 64-Bit Server VM (Zulu 8.42.0.23-linux64)-Microsoft-Azure-restricted (build 25.232-b18, mixed mode)
    [root@account-tn-9bcc7dc9-6tm2h /]# cat /proc/version
    Linux version 5.4.0-122-generic (buildd@lcy02-amd64-095) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)) #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022
    1 天前
    回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
    @itakeman #94 v2 很多帖子,咱也不是张嘴就来,你统计一下就知道谁天天碰瓷了
    2 天前
    回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
    @javak 同样的代码,你测试一下 nodejs ? Java 应该比 nodejs 还要少点的
    2 天前
    回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
    @diagnostics 试了下 OP 的代码,在我的 M1 在也是 14M ,可能是平台实现的差异。

    另外 OP 那么纠结内存问题,麻烦解决一下因为伪共享,所以需要在 L1 级别的缓存行加 Padding ,导致缓存浪费的问题。设计一个解决方案,毕竟 L1 内存比 Main Memory 值钱多了,速度也更快。

    那么为了来了,纠结这些内存的所谓底层开发(大多数都是 Golanger ,他们才有闲情碰瓷 Java ),不知道写自己的应用时,设计时,有没有去看第三方的网络库,是如何处理伪共享问题的~~是如何把内存用到极致~
    我猜没有,因为如果他们去思考了,很大可能会像我,认知到了“计算机就是时空之间的 TradeOff”,这个在学算法的时候就会告诉你了。
    也可能国内外的大神都像“草台班子”(虽然我很恶心这个词),能用就行吧~
    2 天前
    回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
    很奇怪你怎么测试,我这边直接编译后跑运行,内存只有 14m ,用 jdk21 更低才 13m ,对比 nodejs 还更低

    我在想,你写 java ,但是完全不懂虚拟机这一套运行机制?那你的技术水平难以恭维啊?和其他带 JIT 、虚拟机的语言比,Java 开销横向对比没有特别夸张的。

    拿去和 C 、Rust 这种对比,肯定比不上,但人家有 JIT 吗?编译速度如何?可能大多数这种水平的 “Javaer” 只会背 AOT 和 JIT 之间的区别,不去思考为什么有这两种设计吧~

    92597 node 0.0 00:00.11 7 0 30 15M 0B 3504K 92597 91889 sleeping
    94005 java 0.0 00:00.28 22 1 87 14M 0B 0B 94005 93035 sleeping



    ```
    public class Main {

    public static void main(String[] args) {

    while (true) {
    try {
    Thread.sleep(1000);
    } catch (Exception e) {
    System.out.println(e);
    System.exit(1);
    }


    }
    }

    }
    ```

    ```
    function sleep(ms) {
    return new Promise(resolve => setTimeout(resolve, ms));
    }

    async function main() {
    while (true) {
    try {
    await sleep(1000);
    } catch (e) {
    console.log(e);
    process.exit(1);
    }
    }
    }

    main();
    ```
    3 天前
    回复了 ljzxloaf 创建的主题 程序员 你们会用乐观锁来防止并发冲突吗
    @samtofor #5 OP 说的乐观锁是应该是依赖数据库避免并发冲突的
    3 天前
    回复了 GeekGuru 创建的主题 Android 从 iPhone 换到 Android 的阻碍居然是拍照?
    现在安卓确实过度美颜,摄像头即使 CMOS 一样,也会故意不给优化。

    还有一个问题是,取景器的设计问题,移动 iPhone 让人感觉是个方框里面(和相机一样),移动安卓来拍照让人感觉有个纸片在那里,而且那个纸片还会前后移动。。。(录像时更明显)
    @IamUNICODE #39 定位工具都有,那排查问题还要 2 天,不就是经验问题吗?多在 dev 环境练,没问题吧?

    另外,遇到问题,能反思的点很多,上来对架构做出质疑的,你别在 V2 发帖子,怼你领导,怼你 CTO 啊,你又没胆子,有胆识说服老板让你当 CTO/架构师,改为单例。

    上面的话说的不好听了点,但良言难劝该死鬼,你这不是技术能力问题,而是态度问题了。

    冯诺依曼架构在现代计算机上还有性能问题呢,人家也是混合哈佛架构去优化了才是我们现代处理器的模型,难道你要设计师推倒重来?回到我的论证:你觉得在这个 path 下微服务架构不好用:

    1. 优化流程,减少微服务的拆分(不是无脑拆,而是有必要的拆分),至于有个哥们回复我负载均衡网关+单体,我都不想搭理他(这难道没拆服务?说白了他就是学艺不精,别人上个帖子也是写了并发的软件,并发都没吃透,培训班水平)
    2. 构建组织的优化:你的问题其实是这个,library 没升级和微服务压根不搭边好吧
    3. 升级流程的优化:上线没人审核评审变动,需求开发前没评估升级风险

    这些点都可以是问题的优化,对于你的问题,压根不在微服务,你这是 Structuring Projects 的问题,但你觉得为什么部分包要单独抽出来外部引用?就是为了一个 schema 升级时,上下游都可以同步开发,不依赖这个 schema ,如果一旦 schema 升级,是需要上下游找到对应的人的。(你可以参考今天的帖子: https://v2ex.com/t/1057143

    另外升级检查,也可以写个 maven 插件来搞定(假设你是 java 项目)

    八杆子打不到微服务架构上。。。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1080 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 23:12 · PVG 07:12 · LAX 16:12 · JFK 19:12
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.