V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  cloudzhou  ›  全部回复第 69 页 / 共 88 页
回复总数  1746
1 ... 65  66  67  68  69  70  71  72  73  74 ... 88  
2016 年 1 月 21 日
回复了 nekocode 创建的主题 Python [新手开源] 使用 Tornado 搭建 RESTful 接口服务
我想问一下 mqtt 用在哪里?
这个人是在透支自己的信用啊
2016 年 1 月 10 日
回复了 eightqueen 创建的主题 程序员 git 如何指定某个文件暂时不提交?
git status|grep modified|grep java$|awk '{print $NF}'|xargs git add
2016 年 1 月 8 日
回复了 honmaple 创建的主题 Redis 怎么用 redis 存储用户操作?
sortedset
2015 年 12 月 29 日
回复了 tooweakchen 创建的主题 Python 有什么好的 go 的资料吗?现在是 python 转 go
@sun2920989 the way to go 很不错。
umeng_devicetoken=MySQLdb.escape_string(web.utf8(data.get('umeng_devicetoken','')))

这段话看起来是使用了 sql escape_string ?
data.get('umeng_devicetoken','') 是 http 的 GET 获取参数?
然后使用 utf8 变成字符?

建议你还是一步步学起来吧
2015 年 12 月 10 日
回复了 dbow 创建的主题 程序员 golang 经验交流, 如何避免 gc 杀手
```go
package main

func main() {
b := make([][]byte, 3000000)
for i := 0; i < 3000000; i++ {
buffer := make([]byte, 1024)
copy(buffer, []byte("abcd"))
b[i] = buffer
}
}
```

你这个例子来说几乎是无解的,因为无论如何变量会被引用到,所以 GC 本身不会回收的,哪怕使用 sync.Pool ,这种情况下和 GC 关系不大,哪怕你使用 Java ,一样遇到这个问题。

** 所以你的问题是,如何能够更加“紧凑”的使用内存,避免内存碎片。**

按照你的这个例子,那么就是大量的循环里面创造 slice ,但是 slice 很大,而实际存储内容比较小。
“看起来内存很浪费”

解决方法来看:
1 如果使用自己开发的内存池,在大量动态变化情况下,实际上,你就是在实现一个小型的 GC 了。并且不会比使用 sync.Pool 好多少的。
2 借鉴 memcache 的解决方法,申请大的内存块,然后按照长度切片,比如 128b, 256b, 512b, 1k, 2k ,然后根据实际数据做一些 copy 工作。
3 sync.Pool 和 按照长度分片的 buffer 结合起来,基本能实现你的需求了。

节省内存和避免 COPY 是一个矛盾的问题,内存越紧凑,当长度变化时,需要申请新的空间, COPY 数据,反之就是内存越浪费,这是一个权衡的问题。
2015 年 12 月 10 日
回复了 dbow 创建的主题 程序员 golang 经验交流, 如何避免 gc 杀手
@dbow 参考我上面提问,我是想知道这个问题是什么,如果你能提供示例代码就更好了。
2015 年 12 月 9 日
回复了 dbow 创建的主题 程序员 golang 经验交流, 如何避免 gc 杀手
-- while {readline} 不建内存池这种模式下, 10 亿行文本, 吃内存嗖嗖的, 慢点是没有关系的.

我并不理解你这个需求,如果你能提供更多代码就更好了。因为在 while 里面,最终只是复用一个 slice 而已(当然在超过当前长度的时候会申请新的内存空间), GC 应该是可控的。
// 使用 *bufio.Reader ReadLine

上面提到的几种方案, sync.Pool , bytes.Buffer ,有什么理由不能用吗?
2015 年 11 月 17 日
回复了 ncisoft 创建的主题 Java 请教 JAVA 服务器现在是怎么处理大量的连接的?
@ncisoft 后面的 service db layer 这一块,在各种语言都是类似的,由类似“协程”的概念执行。
也就是说,并没有完全的异步,比如 orm 这一块。
现在多并发的解决方案,都是监听 M 个链接,如果有读写操作,就激发对应的行为,有使用回调也有不用的,不用的你可以理解为语言级别帮你做了。
在 Java 里面,也不是一个链接起一个线程,而是把这个链接的 Context 关联起来,当激发回调方法之后接着进行处理,和线程关系是 M : N 的模型, M 是链接数, N 是线程,其中 M 远远大于 N 。

类似 Golang ,是一种比较激进的做法, Goroutine 是一种非抢占式的运行,直到因为 IO 事件进行切换,所以对线程数需求非常的少。
2015 年 11 月 17 日
回复了 ncisoft 创建的主题 Java 请教 JAVA 服务器现在是怎么处理大量的连接的?
@ncisoft 如果你单单指的是性能的话, netty 绝不逊于其他各种语言的实现方式。对于 Linux 机器,说到底都是 Epoll 模型。 Netty 基于函数回调,并不是需要依赖于大量的线程。
2015 年 11 月 12 日
回复了 sbmzhcn 创建的主题 Linux cat /var/lib/radom_salt | md5sum 不生成随机字符
cat /proc/sys/kernel/random/uuid | md5sum
2015 年 11 月 12 日
回复了 Andy1999 创建的主题 程序员 Redis 未授权访问配合 SSH key 登录已中枪
最最简单的,难道不应该使用 iptables 吗?只把需要的端口开放出来
2015 年 10 月 31 日
回复了 hzgmaxwell 创建的主题 Vim 美国人民其实也挺认真的,我丢人了
@anthonyeef 我觉得你的解释不像是,你那种代入感是日本人的方式
2015 年 10 月 30 日
回复了 hzgmaxwell 创建的主题 Vim 美国人民其实也挺认真的,我丢人了
看起来很多人还是不理解这个老外的回复,这个回复其实蛮有意思
英语要注意一下语境,我尝试简单来翻译一下:
...前面大家懂...
I've also studied a few languages so I know how hard learning a language is.
So please don't take my corrections badly. :)
我以前也学过一些语言(不是指编程语言,而是中文,英语等...),我知道学习一门语言有多难
所以不要把我的改正理解为恶意。

English is very confusing. As I've studied other languages, I've realized how bad it
is. I'm sorry. Sorry can mean "my fault, I created English" but in this case I mean
"I feel for you" because I didn't create English. :)
英语很容易让人困惑。当我学习其他语言后,我理解到多么的难(指 confusing )。
"I'm sorry". Sorry 可以理解为 "这是我的错,我创造了英语" // 要理解这时候老外的幽默之处 :-)
也可以理解为 "I feel for you",就是我对你感同身受,很理解你,因为我并没有创建英语这门语言。

老外指的是 "I'm sorry" 这一句本身就有两种意思,然后幽默的举例表示英语的 confusing 。

有趣的是,
@hzgmaxwell 貌似并没有 got it ,在回复的时候问:
What do you mean by I feel for you? I see nothing sorry here. ...

-----------------------------------
以上是我的理解,看看有错没 ?
2015 年 10 月 29 日
回复了 foru17 创建的主题 生活 搞IT,健康伤不起啊。
@StackGao 习惯性扭脖子
2015 年 10 月 23 日
回复了 qiayue 创建的主题 分享发现 tinyfool : 我前妻的故事(一个初中肄业生的奋斗)
@LichMscy 我真的很难想象有些人对陌生人的恶意,以及语言上的暴力,这是人性之恶。
2015 年 10 月 23 日
回复了 qiayue 创建的主题 分享发现 tinyfool : 我前妻的故事(一个初中肄业生的奋斗)
我关注 tinyfool 很久了,并不喜欢他,因为话唠、愤青,但是他是一个心地好的人。
前面几个评论其前妻的用户,真的让我大开眼界。
一个女子和你结婚,生儿教女,可以说真是最大的机会损失了,双方都共同付出。
如果你不是真的对双方很了解,就请不要轻易评判。
-- 致那些臆想、直男癌的 sb 们
2015 年 9 月 14 日
回复了 xing393939 创建的主题 云计算 阿里云的客服就是这样做事的?
@cloudzhou 但是磁盘读写实在太差了
2015 年 9 月 14 日
回复了 xing393939 创建的主题 云计算 阿里云的客服就是这样做事的?
个人认为这种沟通态度是无济于事的。
虽然很多人黑阿里云,但是我使用是非常稳定的,现在线上有 3 台 机器。
作为前员工,贴图表示支持:-):
git@AY130424123630994f09:~$ uptime
14:29:04 up 721 days, 22:32, 2 users, load average: 0.16, 0.05, 0.06
1 ... 65  66  67  68  69  70  71  72  73  74 ... 88  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2134 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 40ms · UTC 14:47 · PVG 22:47 · LAX 06:47 · JFK 09:47
♥ Do have faith in what you're doing.