@Trim21 #46 据说是 5 月 26 日。

使用 netty 可以很简单的处理吧，实现一个自定义的 ByteToMessageDecoder，首先标记一下读取位置，然后读取 4byte，得到消息长度，如果 ByteBuf 的剩余长度足够，就直接读取消息长度的内容，否则 return 并等待下一次读取，直到剩余长度满足消息长度。或者如果你不想一次读完，就每次读取就放到一个 byte 数组里面，直到 byte 数组满足待读取的长度。

@ychost #23 毕业了以后再也没有当年天天在六维做种的感觉了，可惜了我的 10 多 T 的上传积分

手持 25 寸 2k 和 27 寸 4k，windows 环境。个人更推荐 27 寸 4k，200%缩放下的字体细腻程度还是非常讨好人眼的，虽然显示内容略少于 125%的 2k，但是体验真的更胜一筹。

本来想迁移 j11，看评测发现 j8 的性能是目前最佳，还是 j8 吧。

@wang93wei #6 目前主流的厂商推送通道一般是华为，小米，apple，魅族，oppo 和 vivo （还包含他们的子品牌），其他基本都需要靠 App 自己，推送触达率很低的

这么多维度嘛？不会是把一个维度的多个值都拍平了吧。。

作为一个 java 开发，感觉同价格 windows 的体验会更好。就目前使用而言 7k 的 windows 主机比 MBP 15 中配体验好，17k 的 precision 5540 更加比 MBP 15 2018 款中配的体验好。除了 windows terminal 不支持 lrzsz，其他我觉得和 iterm2 差不多。作为一个使用了两年 mac 切换回 windows 的 java 开发者如是说

List.size()方法返回的是当前 list 已有的元素数量，Collections.copy 这个方法比较的是已有元素的数量，因为没法取得 list 底层数组的实际容量，所以通过比较已经填充元素的数量代表这个两个 List 的最小实际容量比较。关键点是不暴露底层数组的实际最大容量，才使用的已填充数量做比较的。

27 寸 4K 200% 40cm 距离

@Showbox #9 [捂脸]表述不清楚，win10 v20H1，因为是说四月底到五月推送，简称 2004

@Showbox #2 据说 2004 是 4 月底到 5 月底推送

AdoptOpenJDK +1，现在家里的 windows 和工作用的 mac 都是用这个了

求支持 rz 啊! ORZ 就只有这一个痛点了

因为基于类目行为的推荐通常来说效果最容易体现。做画像的都听过啤酒与尿布的故事，但是实际上还是看工业啤酒推精酿啤酒的效果好，这只能说技术还是不够啊

第一，如你图上的示例，确实使用 Optional 和判断是否等于 null 没有区别，因为你的条件分支里面没有使用 str 这个变量。在此情况下，我认为没有区别。
第二，假如你的条件分支有使用 str，那就需要对 str 为 null 的情况赋予其他值，此时可以使用 Optional.orElse("default")或者 Optional.orElseGet(()->"default")这样的方式来代替使用 str 。
第三，还有一种情况是 str 等于 null 我要抛异常，很常见，例如 DB 里面查不到数据我要抛异常，此时可以使用 Optional.orElseThrow(() -> new StrNotFoundException("str 没找到！"))类似的.
综上，不是什么情况下 Optional 都能达到你想要的效果，不过最差的基本面也是和判断是否为 null 类似，所以可以尝试去使用

方案 1 的思路绝了！！

目前使用的是 Dell Precision 5540，也是代替了公司的 MacBook，可能我更加习惯 windows 吧。5540 上的是 4k 非触摸屏，windows 的 4k 显示效果也是杠杠的