V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ppyybb  ›  全部回复第 4 页 / 共 16 页
回复总数  305
1  2  3  4  5  6  7  8  9  10 ... 16  
2020-03-03 15:05:35 +08:00
回复了 ppyybb 创建的主题 酷工作 「Hulu 北京研发中心内推」
@JasonJoo 可以的
2020-02-27 11:01:06 +08:00
回复了 ThanksSirAlex 创建的主题 职场话题 坐标上海,两年半后端开发市场薪资水平大概是多少
@metrue 感觉里面有些乱写的,我看调查标准是算上股票 /期权和年终奖了,那么有的 p8 200,有 p
8 的 75w 感觉有点扯. 还有头条 4-1 才 200w 感觉也不可信,3-1 好多就到 150w 了...要不就是这些人自己对税前标准的理解没有一致。。。
2020-02-15 13:05:58 +08:00
回复了 ppyybb 创建的主题 酷工作 「Hulu 北京研发中心内推」
怎么才能让一个帖子重新出现(不发一个新帖)
2020-02-15 13:04:44 +08:00
回复了 ppyybb 创建的主题 酷工作 「Hulu 北京研发中心内推」
帖子沉了,不知道自顶能不能顶上去呢
2020-02-13 20:50:25 +08:00
回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
@yangyuhan12138
其实这样做的目的就是不需要所有线程同时 take 啊,不发生冲突就不会有入 sync 的问题,我的原意只是让进入 sync 尽量少即可说明问题。

当然我想复杂了,因为 aqs 是两年前看的内容了,今天临时翻了下细节不熟悉,搞得我想成进入 sync 后就不会出来,忘记后面还有一个 await 会释放锁从而最终所有 node 都会出 sync 了。
2020-02-13 20:33:32 +08:00
回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
@yangyuhan12138 哦,你说的这个也对,await 的时候会释放锁,从而不在 sync 队列里面了。从这个方面来说也是对的。
2020-02-13 20:29:30 +08:00
回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
@yangyuhan12138 又想了下,直接 sleep 一次也是可以说明问题,因为上面没有活跃线程,那么在 unfair lock 的情况下,无论是加锁还是超时都应该一次抢到,因此不用进入 sync 队列, 这个逻辑说的通。

不过公平锁还是可以通过自己拷贝一份 Queue 然后换掉来测试,当然似乎没有这个必要了~
2020-02-13 20:15:44 +08:00
回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
@yangyuhan12138 如果你指主线程再 poll 前只 sleep 一下我认为不能说明问题,这个只影响上面的线程是否执行完毕全部进入阻塞状态,而不影响进入 sync 队列的 node 数量。你这样对测试结果反而看起来更像线程太多影响调度导致而不是 node 太多导致。

如果指的是每次 submit 前 sleep 一下才有说服力是 node 太多导致的。

非公平锁也不能测试啊,你拷贝一份 queue 的代码把锁换了,而且可以测试更多自定义的操作。
2020-02-13 15:30:15 +08:00
回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
@yangyuhan12138

关于 1,我的意思是线程本身没有执行完,不是说线程没有创建完。

其它部分又仔细看了下代码,你说的应该是对的。一开始看的不仔细。

要验证下应该也比较容易,只需要确保每一个 take 都直接执行到 await 那里,这样就不会因为 lock 进入 sync 队列了。

这个应该可以通过在 take 前面加一个 flag 用来告知主线程这里快执行到 take 了,然后再 sleep 一小会。之后再执行下一个 submit。

这种情况下进入 sync 队列的应该非常少或者没有,来对比下会不会出现误差大的情况。

但是多说一句,这么大线程数量的情况下,任何 poll 不可靠都是符合逻辑的,因为 os 调度总需要线程时间...虽然这个 case 里面让别的线程暂时 sleep 住了。实际场景中应该不需要考虑这种情况。
2020-02-13 12:27:10 +08:00
回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
@yangyuhan12138 我在 mac 上试了下,由于 mac 线程数量的限制,我只能用 4000 个线程去试,没有能复现你说的现象。

另外我又看了下 aqs 的代码,
take 应该是一直放在 condition 队列里面,因为没有被唤醒或者超时,不会进入 sync。
poll ( 1000 )则应该是一开始进入 condition,超时后进入 sync 队列。

那么在 sync 里面其实就只有一个元素,不会有很多 node 去争抢锁。而 condition queue 则和队列大小没有明显关系,超时是通过 park ( timeout )+自旋来实现的,和其他节点无关。

有没有可能是你上面 submit 的循环在后台线程实际没有执行完,所以下面的 poll 等的时候实际上还有很多线程不停创建,由于线程太多,os 调度的时候不停切换,很多没有执行到 sleep 哪一步,所以导致 poll 误差太大?你在 poll 直接 sleep 一段时间看看呢
2020-02-11 23:34:57 +08:00
回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
@yangyuhan12138 你这个几秒完全没有根据啊,你前面得有多少 node 才会有这么大误差?我觉得完全没有必要考虑这种不切实际的情况
2020-02-11 21:55:37 +08:00
回复了 yangyuhan12138 创建的主题 Java 了解 AQS 的进来讨论一下
会超过,但是 nanosecond 的精度很高了,差异很小,这就是为什么这个 api 要用纳秒做参数的原因,实际中应该可以忽略误差。
2020-02-05 18:48:29 +08:00
回复了 dusu 创建的主题 程序员 百万级 Hash,十亿个元素,分布式存储和索引选什么适合?
@dusu 原来是集群那你扩大分片不就行了,怎么会有 100g 呢?你说的集群是主从?
2020-02-05 01:01:49 +08:00
回复了 dusu 创建的主题 程序员 百万级 Hash,十亿个元素,分布式存储和索引选什么适合?
你这个限制比较多,又要省钱....要不自己搭建一个 mongo 集群,要不自己搭建 ssdb 集群(运维成本,改动小点),要不试试阿里云混合存储 redis ?
2020-02-05 00:15:41 +08:00
回复了 dusu 创建的主题 程序员 百万级 Hash,十亿个元素,分布式存储和索引选什么适合?
写入是指更新还是增加一个 key ? hash 数量会变化吗? latency 要求是啥
看样子,这个岗位是类似平台入口侧的?
2020-02-01 20:10:55 +08:00
回复了 ITrecruit1 创建的主题 酷工作 机器学习招聘:C++/ Python Developer-60-100 万+6-24 个月奖金-北京
@690690 能稍微说下嘛?比如说钱,这个 jd 上的薪资会用什么方式打折扣?
2020-01-29 22:22:54 +08:00
回复了 ITrecruit1 创建的主题 酷工作 机器学习招聘:C++/ Python Developer-60-100 万+6-24 个月奖金-北京
@690690 这个有啥坑?
2020-01-29 22:10:02 +08:00
回复了 lenghonglin 创建的主题 职场话题 最近在家思考人生,未来是往技术发展还是管理发展
你为啥要盯着重庆,趁年轻去北京或者别的一线见识见识多好,重庆 it 比成都都差远了
2020-01-27 20:24:40 +08:00
回复了 leolin 创建的主题 程序员 一道算法面试题
直观上的理解似乎是 a 个元素取 k 个数,但是这 k 个数又是可以重复的且存在全序关系,因此除了第一个数,再增加 k-1 个数,代表当每一个数需要选的和前一个数一样的那种可能?感觉不太严格,虽然结果肯定是对的
1  2  3  4  5  6  7  8  9  10 ... 16  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2883 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 27ms · UTC 15:10 · PVG 23:10 · LAX 07:10 · JFK 10:10
Developed with CodeLauncher
♥ Do have faith in what you're doing.