 |
bli22ardV2EX 第 597131 号会员，加入于 2022-10-12 11:36:31 +08:00今日活跃度排名 168 |
bli22ard 最近回复了
3 小时 49 分钟前 回复了 bli22ard 创建的主题 › 程序员 › rust 中看似非常简单操作，竟然导致段错误 |
@dogfeet zigbuild 我试了下，使用 rustls ， 指定低版本的 glibc ，比如 2.22 ，那大多数服务器都可以兼容，不知道这样做有没有什么坏处
6 小时 17 分钟前 回复了 bli22ard 创建的主题 › 程序员 › rust 中看似非常简单操作，竟然导致段错误 |
@adoal 感觉有点道理
@dogfeet cargo zigbuild 没试过，我是用 https://github.com/cross-rs/cross 交叉编译。zigbuild 不静态链接，到运行的机器容易提示找不到对应 so 吧？静态链接，最佳实战应该就是 musl 了。
@kagenomirai
glibc 众所周知是不可以静态链接的，这个我见识短，之前不知道。
和 lua 比不合适，lua 需要依赖解释器。rust 和 golang 编译输出都是可执行程序，所以它们比较有可比性。编译和链接这块 golang 难道不比 rust 方便？ go buid 指定 os 和 arch ，就可以了。
@dogfeet cargo zigbuild 没试过，我是用 https://github.com/cross-rs/cross 交叉编译。zigbuild 不静态链接，到运行的机器容易提示找不到对应 so 吧？静态链接，最佳实战应该就是 musl 了。
@kagenomirai
glibc 众所周知是不可以静态链接的，这个我见识短，之前不知道。
和 lua 比不合适，lua 需要依赖解释器。rust 和 golang 编译输出都是可执行程序，所以它们比较有可比性。编译和链接这块 golang 难道不比 rust 方便？ go buid 指定 os 和 arch ，就可以了。
8 小时 2 分钟前 回复了 bli22ard 创建的主题 › 程序员 › rust 中看似非常简单操作，竟然导致段错误 |
@hingle 列的都是客观事实
8 小时 10 分钟前 回复了 bli22ard 创建的主题 › 程序员 › rust 中看似非常简单操作，竟然导致段错误 |
@wolfsun 上来就开喷，不进行一下准备工作吗？比如列一丁点事实？
8 小时 12 分钟前 回复了 bli22ard 创建的主题 › 程序员 › rust 中看似非常简单操作，竟然导致段错误 |
@aloxaf
我测试了一下，musl 静态链接这个代码确实没有问题。linux 静态链接还是得 musl 。
@dilfish 下次可以试试 musl 静态链接
@virusdefender 看来 glibc 确实是不能静态链接。即使静态链接编译成功也是假象，段错误在运行时等着。
我测试了一下，musl 静态链接这个代码确实没有问题。linux 静态链接还是得 musl 。
@dilfish 下次可以试试 musl 静态链接
@virusdefender 看来 glibc 确实是不能静态链接。即使静态链接编译成功也是假象，段错误在运行时等着。
10 小时 4 分钟前 回复了 Renco 创建的主题 › Java › 请教一下关于 Java 泛型的问题。 |
建议
public <T extends V> T get(String cacheKey,K key){
Cache<K,V> cache=cacheMap.get(cacheKey);
if(cache!=null){
return (T) cache.get(key);
}
return null;
}
你是要限定 V 的类型范围，因为你已经限定了 cache 的 value 是个 V 类型。传 Class<T> clazz ， 那你的 V 类型还不如直接定义为 Object 。另外你的成员变量 cacheMap 会有并发安全问题，当然如果 CacheHelper 不会有并发问题，那可以忽略并发安全问题
public <T extends V> T get(String cacheKey,K key){
Cache<K,V> cache=cacheMap.get(cacheKey);
if(cache!=null){
return (T) cache.get(key);
}
return null;
}
你是要限定 V 的类型范围，因为你已经限定了 cache 的 value 是个 V 类型。传 Class<T> clazz ， 那你的 V 类型还不如直接定义为 Object 。另外你的成员变量 cacheMap 会有并发安全问题，当然如果 CacheHelper 不会有并发问题，那可以忽略并发安全问题
6 天前 回复了 hez2010 创建的主题 › 程序员 › 运行 100 万个异步并发任务需要多少内存 |
@kneo
> 栈的特点就是动态增长。因为函数调用需要把子函数的存储也分配到这个栈上。函数的嵌套越多，需要的内存就越多。
> 栈空间不够用就需要重新分配内存并且把旧的栈数据复制过去。（这里指的是虚拟线程，原生线程收到操作系统限制> 可能无法修改栈大小。）
> 如果初始化栈过小，频繁的扩容会影响性能。
> 初始栈过大，会造成内存浪费。
> 2KB 是一个性能权衡的结果。
> 您可能需要找一些函数调用和栈内存的示意图看一下。不一定非是 GO 的。
我找了一些函数调用和栈内存的示意图看了下，2kb 的栈空间是用来保存现场的，go 做了一次预分配，在 op 提到的测试方法，这样预分配在内存占用方面确实会吃亏，反而动态堆分配的会占优势。
> 栈的特点就是动态增长。因为函数调用需要把子函数的存储也分配到这个栈上。函数的嵌套越多，需要的内存就越多。
> 栈空间不够用就需要重新分配内存并且把旧的栈数据复制过去。（这里指的是虚拟线程，原生线程收到操作系统限制> 可能无法修改栈大小。）
> 如果初始化栈过小，频繁的扩容会影响性能。
> 初始栈过大，会造成内存浪费。
> 2KB 是一个性能权衡的结果。
> 您可能需要找一些函数调用和栈内存的示意图看一下。不一定非是 GO 的。
我找了一些函数调用和栈内存的示意图看了下，2kb 的栈空间是用来保存现场的，go 做了一次预分配，在 op 提到的测试方法，这样预分配在内存占用方面确实会吃亏，反而动态堆分配的会占优势。
8 天前 回复了 hez2010 创建的主题 › 程序员 › 运行 100 万个异步并发任务需要多少内存 |
@kneo 就启动 goroutine ，不管是堆还是栈，没搞懂它有什么存，如果是参数，变量，为什么要是 2kb ，而不是这些参数、变量的实际大小
8 天前 回复了 hez2010 创建的主题 › 程序员 › 运行 100 万个异步并发任务需要多少内存 |
@kneo
> 我的理解这 2KB 就是预分配的栈大小。过小的初始栈可能会导致频繁的内存重新分配。
> 2KB 可能是 go 团队在性能测试之后得到的一个比较好的默认值。这个值也是经过多次调整的：
更本质的是，为什么需要这个 2kb 内存，这 2kb 存的什么东西，这个期待有实力的人研究一下 runtime 。
> 我的理解这 2KB 就是预分配的栈大小。过小的初始栈可能会导致频繁的内存重新分配。
> 2KB 可能是 go 团队在性能测试之后得到的一个比较好的默认值。这个值也是经过多次调整的：
更本质的是，为什么需要这个 2kb 内存，这 2kb 存的什么东西，这个期待有实力的人研究一下 runtime 。
9 天前 回复了 hez2010 创建的主题 › 程序员 › 运行 100 万个异步并发任务需要多少内存 |
我不认为这个测试方法不专业，因为它能说明，在这个 sleep 场景下，goroutine 内存占比确实比 java 的 virtual thread 占用高。
我觉的叫 goroutine 为协程并没有什么问题，可能翻译得不够准确，但是当你说 go 协程，别人知道你指的是 goroutine 就可以了，没有什么大问题。
不过我觉得这个测试可能并不能很好的说明问题，不管是 goroutine ，rust 的 tokio ，或者是 c#的 async/await ，它们本质上解决两个问题，一个 io 就绪回调，一个 sleep 就绪回调。但是要实现这种回调，需要在资源没就绪时候，保存现场，腾出 cpu 给其他任务运行，保存完毕后，其他任务运行，资源就绪后，就有了再次被执行的机会。这个内存消耗主要在保存现场需要的内存上。由于这些异步框架实现方式不一，不排除有些实现，检查测试代码不需要保存现场，直接定时器回调实现，从而节省内存。
一种测试方法是通过每个任务去发起一个 tcp 连接，然后服务端 hold 10s 再返回，测试内存占用可能更能说明实际的问题。
另外还有就是执行时间问题，因为如果开一个 goroutine 排队执行，内存占用肯定比开 1m goroutine 小🤣
也有可能 java 的 virtual thread 和 c# async/await 确认非常优秀，全面领先 goroutine ，希望有实力的人从新设计测试方法。
比较好奇，每个 goroutine 2kb ，到底存的是什么
最后 @lesismal @kneo 两位高手来围观
我觉的叫 goroutine 为协程并没有什么问题，可能翻译得不够准确，但是当你说 go 协程，别人知道你指的是 goroutine 就可以了，没有什么大问题。
不过我觉得这个测试可能并不能很好的说明问题，不管是 goroutine ，rust 的 tokio ，或者是 c#的 async/await ，它们本质上解决两个问题，一个 io 就绪回调，一个 sleep 就绪回调。但是要实现这种回调，需要在资源没就绪时候，保存现场，腾出 cpu 给其他任务运行，保存完毕后，其他任务运行，资源就绪后，就有了再次被执行的机会。这个内存消耗主要在保存现场需要的内存上。由于这些异步框架实现方式不一，不排除有些实现，检查测试代码不需要保存现场，直接定时器回调实现，从而节省内存。
一种测试方法是通过每个任务去发起一个 tcp 连接，然后服务端 hold 10s 再返回，测试内存占用可能更能说明实际的问题。
另外还有就是执行时间问题，因为如果开一个 goroutine 排队执行，内存占用肯定比开 1m goroutine 小🤣
也有可能 java 的 virtual thread 和 c# async/await 确认非常优秀，全面领先 goroutine ，希望有实力的人从新设计测试方法。
比较好奇，每个 goroutine 2kb ，到底存的是什么
最后 @lesismal @kneo 两位高手来围观
Select Language