V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Karte  ›  全部回复第 1 页 / 共 11 页
回复总数  204
1  2  3  4  5  6  7  8  9  10 ... 11  
1 天前
回复了 jasonchen168 创建的主题 生活 马路上的噪音,怎么解决
可以戴耳塞. 耳塞很管用
合理, 主要有以下几点:

1. 一个功能一个分支:确保功能完整,便于问题回退,控制影响范围。合并到主线通过 MR ,git log 清晰记录提交范围。
2. 小提交原则:避免一次性提交完整功能。若功能开发中(已提交 5 次)遇 issue ,主线开发需选择回退( revert )或继续提交。前者需重新提交,后者可能因未完成功能导致主线无法运行。而一功能一分支、一 issue 一分支可快速切换修复 issue ,不受未完成功能影响。修复后,切回功能分支,rebase 解决冲突,继续开发。

假设你已经 commit (还未 push) 了 5 个 change, 功能还未开发完成. 这时突然出现一个 issue, 如果这个 feature 在主线而非分支. 那你是打算 revert 之前的提交, 还是直接修改继续提交 (6 个提交).
如果 revert, 那你得先 revert 之前的所有提交, 然后提交 issue, 之后还得重新 commit.
如果直接提交, 那你还未完成的 feature 也同步 push 到主线. 那很有可能会出现无法跑通的情况 (必尽你还未开发完成).
29 天前
回复了 inas 创建的主题 电动汽车 想换个 15 万内的纯电,有什么推荐吗?
@recying5566 哈哈哈哈哈哈, 只要 6 万起, 能拉能运还便宜 [doge].
29 天前
回复了 inas 创建的主题 电动汽车 想换个 15 万内的纯电,有什么推荐吗?
五菱宏光, 混动续航 1000KM +

https://www.bilibili.com/video/BV1SRo6Y2Eaf/
30 天前
回复了 heiya 创建的主题 程序员 对搭建 MinIO 对象存储的一些疑问
@heiya 首先大文件会占用过大的磁盘 IO, 如果云磁盘容量过低则 IOPS 也会很低.

在没有性能要求的情况下, 且数据库和 MINIO 不属于同台机器是可以使用 minio 的. 如果有性能要求, 那磁盘 IOPS 则会是瓶颈. 既然如此可以试试内网 OSS, 或者内网 S3. 内网的费用相对便宜实惠.


对于大文件是否需要 CDN 这个问题, 你得先明白 `CDN (Content Delivery Network)` 是什么. CDN 是一个内容分发网络, 将你提供的资源尽可能的靠近用户侧 (实际请求的用户, 例如 B 站的视频资源), 同时提供海量带宽.
如果你的文件不会频繁下载, 或者根本不会下载, 那 CDN 就不需要了. CDN 引入只会徒增成本 (资源成本 + 流量成本).
30 天前
回复了 heiya 创建的主题 程序员 对搭建 MinIO 对象存储的一些疑问
说实在的, 有 OSS 不用非得自己搭. 图啥啊?

自建存在以下问题:
- 安全措施 (即使 MINIO 有账户校验和链接校验, 但只要有漏洞数据就全丢了)
- 磁盘限制 (云厂商提供的硬盘是按照容量分配 IOPS 的, 你容量越小, IO 越小. 存个大文件直接把 IO 吃满了)
- 带宽限制 (你也说了带宽瓶颈了, 既然你是对外提供服务, 为什么不选择 CDN ?)
- 高可用 (自建没有现成的好)


PS: 如果只是出于学习的目的, 那尽管折腾.
@ebony0319 的确不错👍.
@ebony0319 是的, VT 是 JDK 的里程碑. 在 HTTP 侧的确能够显著的提升响应能力. 不过在日常业务开发中也能使用, 不过需要比原有的 Thread 有更多的规范. 滥用 VT 可能并不会提升性能, 还会降低性能 (上下文 Continuation).

在没有修复 synchronize 情况下, 只建议在最贴近 IO 部分使用, 尽可能减少组建中 synchronized 所带来的影响 (没修复, 也就是 JDK-21-LTS).

在目前的 JDK-24 (non lts) 中修复了 synchronize PINED Thread 的问题, 但类似本地方法调用还是会存在 PIN. 在日常开发是可以使用了, 不过还是需要注意 VT 数量. 平台线程的数量是和计算机硬件资源对等的, 而 VT 数量则是和 JVM 内存对等的. VT 数量越多, JVM 内存占用越高, 直到 VT 任务结束释放了 Continuation.

总结:
1. 在 JDK-21-LTS 不太推荐使用. 如果使用请尽可能贴近 IO 部分.
2. JDK-21-LTS 也能使用, 前提是了解 VT 内部机制 (上下文切换, Continuation, 锁机制, 本地方法站调用).
3. 如果在业务中, 我的建议是等下一个版本的 LTS 上线. 想上也可以, 建议增加 -Djdk.tracePinnedThreads=full, 在遇到 PINNING 时会打印堆栈.
@anyele 我知道
@ychost 我知道, 所以前面增加了 JDK-21-LTS 版本
就目前的 JDK-21-LTS 的虚拟线程还存在致命问题:

- 在使用 synchronized 场景下会将虚拟线程 PIN 到平台线程 (锁在了某一个线程上)
这是由于当前对 synchronized 的实现需要直到锁当前持有的线程对象. 而虚拟线程是上层包装出来的, 所以必须强绑到某一个平台线程 (Thread) 上才能实现. 如果在 IO 操作下会基本和平台线程无异.

- 在 Medium 中, Netflix 团队遇到使用虚拟线程死锁的情况.
这个问题和 synchronized 关联. 具体可以参考 [Medium Netflix Tech]( https://netflixtechblog.com/java-21-virtual-threads-dude-wheres-my-lock-3052540e231d)
虚拟线程不推荐使用.
1: 虚拟线程的出现是减少 IO 的产生, 如果是非 IO 操作使用虚拟线程只会增加应用负担.
2: 虚拟线程是通过用户态上进行上下文切换减少内核态切换. 虚拟线程使用 Continuation 实现的, 这个是个对象, 也就是会占用内存. 当你操作越多, 内存占用也会疯涨. 原有平台线程 (Thread) 则是由物理资源 (系统资源) 限制, 而虚拟线程则没有这层限制, 操作不好容易导致 OOM.
用 var 能够减少类型申明 (虽然可以通过 .val 快速申明), 但是会显示隐藏掉函数返回类型. 如果是一个新人进来看到一堆 var 关键字, 就得对每个方法进行 CTRL+Q 查阅方法返回数据类型, 或者进入方法内部查看, 相对不是十分便捷.

同样的, 由于 var 显示隐藏了对象的结构信息, 可以有效的把冗杂的类名或者泛型隐藏. 整体代码看起来会相对清爽 (但阅读同样存在障碍).

具体用还是不用, 一方面取决于团队内部, 还有一方面取决当前项目构型.
如果项目构型没有使用 var 关键字, 那尽可能不要使用, 会显著增加阅读代码的障碍 (虽然不是很大, 但有些人会觉得很头疼).
如果团队内部都支持, 建议在新项目内使用, 老项目则按部就班.

最好能在使用前与团队内部进行交流探讨, 让团队都了解这个特性, 并尝试了解他们所抵触的原因, 尝试对其进行化解才会更有效的推动新特性的使用.
49 天前
回复了 Cyzc 创建的主题 职场话题 同事离职送礼求推荐
@Karte 还有就是大拇指滚轮, 在看一些资料时很有用 (虽然使用率远不及虚拟桌面切换).
49 天前
回复了 Cyzc 创建的主题 职场话题 同事离职送礼求推荐
Master 3s, 别买 Vertical. 虽然 Vertical 符合人体工学, 但是没有 Master 3s 用的舒服.

3s 比 vertical 多了一个大拇指按键, 可以快速的在多个虚拟窗口中来回切换, 而 vertical 是没有的.
49 天前
回复了 vm97 创建的主题 MySQL mysql 自增 ID 突然变为 int 最大值问题
可以具体看下 com.baomidou.mybatisplus.core.MybatisParameterHandler#populateKeys.

如果我记得没错是这.
49 天前
回复了 vm97 创建的主题 MySQL mysql 自增 ID 突然变为 int 最大值问题
可能是你的 MyBaits 上没有 @TableId(value = "id", type = IdType.AUTO).

有些时候 mybaits 会根据策略自动对 ID 进行赋值, 而不是使用自增主键.
1  2  3  4  5  6  7  8  9  10 ... 11  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2943 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 23ms · UTC 10:55 · PVG 18:55 · LAX 03:55 · JFK 06:55
Developed with CodeLauncher
♥ Do have faith in what you're doing.