V2EX › ledkk 的所有回复 › 第 3 页 / 共 9 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 2 3 4 5 6 7 8 9

❮

❯

2021 年 7 月 20 日

回复了 waibunleung 创建的主题 › 程序员 › 体会到了选型失误+效率不够快而痛失的机会

@waibunleung 当时还在学校，勉强交付，也就没有后续了。

2021 年 7 月 20 日

回复了 waibunleung 创建的主题 › 程序员 › 体会到了选型失误+效率不够快而痛失的机会

之前也遇到过类似的情况，当时对项目没当回事，就随便搞了一版，带着练手的心态搞项目，最后就很尴尬

2021 年 7 月 6 日

回复了 xin1284 创建的主题 › 随想 › 我理想的生活状态

区分工作和事业，当前的工作，只是事业的一部分

2021 年 6 月 3 日

回复了 RichardYyf 创建的主题 › Java › 求助帖，应用集群个别实例 young gc 时间突然飙升该如何排查？

从你发的截图看，年轻代增长很快，且每次 ygc 后都能回收大部分数据，但对应的老年代的空间上涨并不是特别快。这说明年轻代的这些对象基本都是临时对象，达不到常驻内存的条件，你们的 ygc 的耗时比较高。这种情况很可能是由于使用了类似本地缓存的模块，使用了 LRU 相关的策略，缓存的命中率并不高，新产生的年轻代的对象不停的往缓存中扔，缓存快速 LRU 淘汰，从而产生了年轻代被年老代引用的情况。

cardtable 内部只是存储了一块内存是否引用年轻代的标识，实际还是需要针对这块内存进行引用计数，判断年轻代的对象是否可回收

2021 年 6 月 3 日

回复了 RichardYyf 创建的主题 › Java › 求助帖，应用集群个别实例 young gc 时间突然飙升该如何排查？

ygc 耗时高有很多种原因，常见的是年轻代的对象被年老代引用，每次统计是不是可以在 ygc 阶段回收的时候，都需要去年老代看引用的根对象是不是引用计数为 0，这段时间可能会导致耗时比较高。

2021 年 6 月 3 日

回复了 whc7808 创建的主题 › 华为 › 如何评价昨天发布的鸿蒙系统

总算有了第一步了，以后慢慢优化打磨就好了。发布会上体感上没有太惊艳的感觉，期待未来能更好

2021 年 5 月 23 日

回复了 vevlins 创建的主题 › 程序员 › 程序员工作量的主要来源

组织方向不明确的时候，各种无脑的尝试。对老板来说，要从不停的尝试新的成长点，不然公司跟不上对手的脚步；时间紧，产品经理出一个想的不算清楚的需求，要求快速上线；然后写代码的被要求快速上线。

2021 年 5 月 23 日

回复了 mseasons 创建的主题 › 问与答 › 技术写作能赚多少钱？

专业+有技术深度的会比较小众，受众不多，赚不到钱