你赔他点违约金，让他重新找一个，现在房租下降了一些，他不傻的话肯定搬走啊

从大舅妈角度看，你丈母娘那么好心加外婆名字，肯定是拿到不小的好处的。资金溯源只能证明出资，证明不了没有利益交换。如果外婆没有出资，那加名字的时候，就应当写好遗嘱做好公证避免纠纷。这是很大的疑点，上海哪个小区没有房产纠纷？明知有隐患却不提前准备，不免让人怀疑有内情。

闸北火车站？那座桥有电梯啊。

人情冷漠是中日韩城市共性，“不给别人添麻烦文化”。

我比较喜欢这种互不打扰的生活，受不了人情社会。

1. 只有 DV ，没有 OV 和 EV
2. OSCP 被墙
3. 泛解析
4. SLA (大公司非常看重)

为啥只有 DOS 支持低格？因为 IDE 时代(80 年代)开始，HDD 自己已经不支持低格了，支持四十年前的 HDD 低格毫无意义。

擦除数据最好的方式，是用随机数据覆盖个 N 次，神仙也还原不了。记住，一定要用随机数据，如果是全 0 或者全 1 ，遇到傻逼固件可能不会真写入，只是给你整体标记。

@Mrzhs 应届生薪资分两种，大白菜和 SP ，按照大厂大白菜路线，应届 20W-30W ，然后熬几年或者跳槽到 50 万也是很快的。当然这是以往经验，现在就业是远不如从前。如果技术很强，能拿到 SP ，应届生 50W 以上的也不少，这对算法或者论文有一定要求，C++写的再好也不能单靠这个拿 SP(2016 年之前可以)。

地方银行的柜员普遍要背揽储 KPI ，你有关系能拉存款就能混的很好，反之有压力。

银行也不是十年前的银行了，上海某银行降薪，直接从 20K+月薪砍到 10K 以下，南京的银行也降过了。

小地方商业不活跃，房地产濒临崩盘，财政非常紧张，银行业恐怕也会越来越困难，现在 35 岁以下的银行职工甚至区级公务员，不一定能干得到退休。

C++程序员，有护城河不假，但大部分人的护城河只能保障到 40 来岁，除非这个赛道钱太少或者有极强的业务知识壁垒，否则根本不愁招不到技术很强的年轻人。

你学历不错，可以直接落户上海，至于是进私企狠赚大几百万再回老家，还是考上海公务员，不急于一时决定。

选技术能力最强的那个团队

这要搞 3 个月，干脆推倒从零开始

tail -f 不是 grep ，基本上不消耗 CPU ，也不消耗内存，每天才 10G ，由于是顺序读，且大概率在 VFS cache 中，也不消耗磁盘 IO 。那么唯一的消耗就是带宽，大概占用 2M-3M 带宽，如果服务器带宽小于 10M ，可能能观测到性能差异。但是直接下载，不是更消耗带宽么？

反问面试官，最近公司项目中都落地了哪些新技术

Goroutine / Coroutine / Virtual Thread / Async-Await ... 名词一大堆，大家的共同点，都是提供比 OS thread 更轻量的并发执行上下文管理。提供这个设施的主要原因，无非是为了解决写复杂回调代码时的心智负担。

内存占用差异，本质上就是这些实现在 stack 实现上的选择，大致有 2 类，
stackful ，Goroutine 这种跑上来就分配 2KB/4KB 的栈，1M 并发时内存就要 2G/4G
stackless ，async-await 方案大都如此，因为无栈，内存占用往往有很大优势


把这两种方案放在一起 PK 内存占用，stackful 天然吃亏。Java virtual thread 本质上也是 stackful ，只不过很取巧的使用了可变尺寸栈，JVM 可以动态调整栈大小，不需要一开始就分配的很大。

stackful 和 stackless 都是上个世纪的理论了，这些语言的设计者们不可能对此不精通。那为何没有一边倒的选择某种方案？显然是两种方案各有利弊。我不谈底层实现差异（主要是不懂），也不谈哪个更强（于我都够用），仅从使用者的角度谈一下感受。

一，函数颜色问题。很多协程的实现，会把所有 IO 函数分成两类，一类会阻塞线程，另一类会挂起让出线程，两者之间往往不能互相调用，Kotlin 的 suspend 关键字就是给函数打标记用的，有些语言用 async 来标记也是一样的。使用这类语言的时候，我们需要清楚的了解调用的方法是不是能用于协程，使用第三方库甚至标准库的时候，也要小心翼翼，一旦弄错后果非常严重。

二，是否抢占式调度。非抢占式调度，需要使用者自己主动交出资源，很多实现提供了 yield 方法/关键字，避免大循环独占线程太久饿死其它协程。

Virtual thread(JVM)和 Goroutine 很好的解决了这两个问题，在集成第三方库的时候，基本上(当前版本 JVM 不能 100%做到)不用考虑会不会阻塞线程的问题，牺牲点内存提高开发效率，是好事还是坏事，没有定论，这要看具体的场景。

理想中的协程应该是这样的，
1. 足够轻量，fire and forget ，不需要 pool ，即便 pool 化了收益也很小
2. 函数不分类，不存在不能用于协程上下文的函数
3. 抢占式调度

但这 3 点根本无法同时实现，Go 和 JVM 都选择了 2 和 3 ，Go 在 2 上面做的最好，毕竟你想写出点阻塞 OS thread 的代码还要动点脑筋。JVM 在 1 上优化的比 Go 好，Java 官方文档敢写“Represent Every Concurrent Task as a Virtual Thread; Never Pool Virtual Threads”。

题外话，有了很轻的协程，就可以肆无忌惮的开了吗？并不是，DB 扛不住啊，所以像 Kotlin 这种 1G 内存能开 2M 个协程的语言，也特地提供 limitedParallelism 控制协程的并发度。这是调度层面做的，不一定要用协程池的方式来做。

@lesismal 66#

However, when code running in a virtual thread calls a blocking I/O operation, the Java runtime suspends the virtual thread until it can be resumed. The OS thread associated with the suspended virtual thread is now free to perform operations for other virtual threads.

Java 的 virtual thread 就是为了解决传统线程阻塞时不能让出 CPU 资源提出的方案，如果请求 SQL 就卡住线程了，那就不需要在 JVM 层面提供支持了，完全可以像 Kotlin 一样从 lib 层面支持，调用者自己确保不会阻塞。

大 A 最大的优点就是稳，3000 左右好多年了，总能有低价捡漏的机会。
跌入 2950 开始分批进场，3000 点以上陆续出货。
上证指数 ETF 还是有分红的，去年分红三次，其中有一次高达 5%。

如果你不贪心，资金量也不大(千万以下)，只追求年化 10%左右的收益，即便大 A 也很容易。

import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking


fun main(args: Array<String>) {
println("stated")
runBlocking {
val numTasks: Int = args[0].toInt()
for (i in 1..numTasks) {
launch { delay(30_000) }
}
println("launched")
}
println("finished")
}

Kotlin + OpenJDK 21 ，1M 个协程 488M 内存(RSS)