g*****g
发帖数: 34805 | 1 如果你设timeout, 是不会出现你说的这种情况的。你说的这种情况发生就是死锁了。
一直呀，不是一次。
而且不管你失败不失败，顺序锁，就可以保证你说的情况不发生。
“然后一直没人拿A,B，结果两个事务下单的人就抓狂了，明明
有票，就是拿不到” |
|
z****e
发帖数: 54598 | 2 而且路经权重必需最短，这个要求很reasonable
没有人会买绕道票的
这个要求加上去，很容易就死锁了 |
|
z****e
发帖数: 54598 | 3 显然么
我从北京回家，你让我先经过广州，那我肯定不干
现在全国八纵八横，这里面没有死锁我就不信 |
|
z****e
发帖数: 54598 | 4 这个需求加上去，直接挂了
图论最短路径到现在理论都无解啊
除了穷举，但是一旦穷举的话
查票出票锁票就很恶心了，并发上5w达成死锁没问题
了。 |
|
q*c
发帖数: 9453 | 5 不能联票那就太容易了吧，每条线一个服务器数据库。。。
不过你基本上买了前段的票就没后面的，娃哈哈， 然后不断退票买新票 进入史无前例
的人工死锁局面。。。 |
|
z****e
发帖数: 54598 | 6 我现在有极强烈的预感
如果不挑硬件，那也就是一个instance的话
500w/s光查恐怕都撑不住
一个cpu估计是不够的
如果多个cpu，这里有调度的问题
很容易会死锁 |
|
z****e
发帖数: 54598 | 7 你这种就是属于典型上下文不看就开始扯淡的
我现在不需要跟你说那么复杂
就假设你们做的cache都能成立
好吧
我告诉你，500w/s的数量级
就是最简单的hash都能算死你，让你直接崩掉
不信写出来试试，这里大概有50个车站，估计还不止
那来回就有50*49这里就大概2500个路径要存了
hash假设这里无碰撞，这个最理想了，不算难为你了
就是这样，我还是觉得500w/s是找死的节奏
也就是光查都不够
如果是一个cpu的话，基本上没戏，两个cpu就要处理死锁的问题
事实上这里动态路径一定存在
a->b->c->d->e
中间如果c->d段没票了，有人要买从a->e段的票
这个时候必须绕道，你怎么办？
这个时候就要近似解，这个时候就两种可能
当场算，或者再从一个cache中取，当场算500w/s不用说了，肯定死
从cache中取的话，那就不只2500个组合了，上5000个小意思
这里又有碰撞问题
我现在不需要说太复杂的东西，就是最简单的需求
500w/s，就撑不住了 |
|
z****e
发帖数: 54598 | 8 老魏要做到REAL TIME
你的方案是异步，回避了类似的问题 |
|
l*****9
发帖数: 9501 | 9 real time是扯淡。十分钟出结果怎么不行了？老魏搞了半天就是个计数器，离卖票系
统还差十万八千里呢 |
|
|
g*****g
发帖数: 34805 | 11 就是说明太监扯谈罢了，看来大家都明白了，我目的就达到了。他不要脸我还能把它怎
样。 |
|
|
l*****9
发帖数: 9501 | 13 客户可以提出组合票，多次中转。系统实现起来不涉及图 |
|
z****e
发帖数: 54598 | 14 这个帖子很精辟
难道不是么？
老魏搞了半天就是个计数器，离卖票系统还差十万八千里呢 |
|
g*****g
发帖数: 34805 | 15 是个太监版的计数器，不保证公平，也不保证票都能出。 |
|
S*A
发帖数: 7142 | 16 要看冲突情况了。这个问题就跟 spinlock 要循环几次
是一样的啊。但肯定不会死锁。 |
|
a***n
发帖数: 538 | 17 嗯，确实不会有不出票的情况。不过所有的票要排序出，否则会有可能两个线程死锁。
而且还是有可能第三个人把票抢走了。 |
|
L*****e
发帖数: 8347 | 18 那就更不理解了，既然是累积的，干嘛堆到一天中来处理？而且backgroud check需要
同步干嘛，不立刻给结果别人要接别的地儿的offer了？然后是同步45分钟，异步3分钟
出结果，只能说明一个问题，你们的同步写的有问题，每个candidate的backgroud又不
是耦合数据，你们还做出死锁来了？还是说这几千人之间有各种各样亲戚关系，公司的
雇佣规则是五服以内的亲戚不能在同一公司打工，所以数据是强耦合数据了？
还是说虽然广告是几千openings，但是位置实际上只有一个，你们做的是几千人的抢位
置系统，backgroud check先做完的先得？
★ 发自iPhone App: ChineseWeb 8.2.2 |
|
n*****t
发帖数: 22014 | 19 单一个车次不存在抢票，按次序来就是了，一个线程管一个车次，一台机子管几个车次
，前端分门别类发请求就是了。这也是古德八最原始的想法，3000 台机子搞定 12306
，拿钱走人。
实际情况有那么简单吗？联程、邻座，这些都要跨数据库或者线程或者服务器，怎么协
调调度，怎么避免活锁死锁？ |
|
z****e
发帖数: 54598 | 20 re这个
内存泄露，死锁都是一般大项目中灰常头疼的问题
dump |
|
b********e
发帖数: 595 | 21
死锁容易定位，tomat直接kill -3, jboss通过jmx能看到heap dump, tda一看就能看出
来，查内存泄漏的确是个力气活 |
|
s*****r
发帖数: 43070 | 22 这要羡慕死锁男了，锁男最期盼的就是面试妹子
这边的锁男饥渴地讨论东莞小姐，气质啥都太高大上了，肤白胸大才是锁男关注的 |
|
g*****g
发帖数: 34805 | 23 光executor, task之间无关的都不好意思说是多线程。怎么也得是一堆的Future,
CountDownLatch, Lock, 在threadpool里还有先后关系，一不小心会死锁的才能叫多线
程。 |
|
n****1
发帖数: 1136 | 24 这个我才发现, 震惊了.不过还好是library, 不是language primitive. 莫非要程序员
手动避免死锁?
可能像java里面的jni允许手动管理内存一样, 不想把事情做绝,但我感觉后患无穷. |
|
H****S
发帖数: 1359 | 25 Semaphore是non-reentrant的，参考以下代码：
def foo() {
println("smile")
super.foo()
}
一个binary semaphoreh会出现死锁。 |
|
i**p
发帖数: 902 | 26 Java synchronized method 在同一thread里是可以多次进入的. 锁是在thread上的.
C++ mutex 在释放之前被同一thread再次调用会造成死锁, 它是锁在mutex这个变量上
的.
请评论. |
|
z****e
发帖数: 54598 | 27 举个例子
class A
A有个对象是a
如果你啥都没做的话
那么这个a并不是线程安全的
为了线程安全，人们想出了各种方法
比如一种线程安全的机制就是lock
但是lock会带来各种狗血问题，比如死锁
而另外一种机制就是immutable
每个thread访问时候，拷贝一份副本就是了
但是这也会带来各种问题，而且不利于理解
fp的狂徒居然发疯了一样要求人们接受什么都是常量的想法
神经病
然后spring什么则是不做控制，你自己要留意
这样就加重了你写代码时候的负担，等于什么都没有做
然后node干脆就干掉多线程，用单线程来做
多线程启动多个process，但是这样的话
你自己要去管理process，以发挥最大机能
尤其是多个cpu多个core的环境下，也麻烦
然后ejb说我可以保证每个instance，一次只会被一个thread所访问
就木有问题，但是这样并发量大的时候，有些操作会导致thread堵塞
就是同步操作，所以ejb并没有很好滴address大并发的问题
虽然提出的构想和目标很美好，但是实现的手段不够好
很多人还是选择了spring那些
但是有了异步之后，大量block的操作... 阅读全帖 |
|
z****e
发帖数: 54598 | 28 一般对于java 内存的评估主要介于两点
一点是怀疑有memory leak，这个对系统伤害很大
所以监控看看有没有什么问题，还有死锁之类的
但是现在都lock free了，一般也不太容易搞出后者来
另外一点是gc的停顿时间，这个对于一些游戏的server来说
会比较敏感，所以会监控看看gc需要多长时间
但是你这个貌似不是游戏也不是什么memory leak
不太明白你为啥要去监控内存？ |
|
g*****g
发帖数: 34805 | 29 还分析哪？你丫弄个系统都不保证不死锁活锁，还看个屁呀。 |
|
g*****g
发帖数: 34805 | 30 做个thread dump, visualVM 就可以查有没有死锁。至于race condition是没啥软件能
查。 |
|
|
r***s
发帖数: 737 | 32 您老还是找本分布式数据库的教课书看看吧
看书不丢人
分布式系统里这些问题怎么解决很多年前就有很成熟的方案了
现在大家不用原因是在表很大的情况下的速度问题， 以及速度
问题带来的死锁问题，而不是在分布式系统下transaction 没法做的问题。 |
|
|
|
|
|
c*********e
发帖数: 16335 | 37 grep -i keyword -R .
或者
grep -i keyword -R . >> output.txt
有问题吗？ |
|
|
|
|
A*********l
发帖数: 2005 | 41 这个不是recursive，这个是正反馈：
grep不停的把grep到的东西写进同目录下的输出文件中，又会从这个输出文件中继续
grep（显然这个是一定会grep到结果的），然后继续写，继续grep，可以说是某种意义
上的死循环。
根本原因就是“搜索完了”这件事就不会发生。 |
|
h**********c
发帖数: 4120 | 42 耍赖的讲，讲一个进程，process不等没有讲多个线程,threads，wiki也不是教科书，
教科书还要改行星的数量呢。
没有其他的选手再猜猜出题人还有什么考点 |
|
|
|
|
|
c*********e
发帖数: 16335 | 47 grep -i keyword -R . > ../output.txt
这个该行了吧？ |
|
b*******s
发帖数: 5216 | 48 --exclude=
most people use ctags will need this |
|
b*******s
发帖数: 5216 | 49 alias GREP='grep -R --exclude="tags" --include="*.cpp" --include="*.h" --
include="*.c" --include="*.py"'
copied from my .bashrc |
|
b*******g
发帖数: 603 | 50 单线程当然是支持的，但是throughput肯定不行，所以你尿遁了。SSA的fix是肯定不行
的，在某些输入底下会一直死锁。不服你让他上来现身说法，正确性这种东西是没有概
率一说的。 |
|
