新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
稍有积蓄, 积分 330, 距离下一级还需 170 积分
论坛徽章:0
今天和同事讨论一个问题，大家对这个问题有点分歧，在这里想听听大家的意见。
情景是假如有多个线程，对同一个socket（tcp)进行写操着，是否需要对这个socket进行加锁．
我的意见是不需要对socket进行加锁的，因为从来没见过这样的做法，而且感觉这些问题操作系统
或者说是tcp/ip协议应该都处理了，这仅仅是感觉．另一种意见说在写的过程中有可能写了一半的
数据到缓存中，发生了切换，另一个线程也可能写了些数据到缓存中，有可能导致接收方收到的不是
一个完整的包（混杂了２个线程写的包）．我对这个说法感到怀疑，但是搜不到切实的理论依据，希望
在这方面有研究的高手们或者遇到过这个问题的同志们讲解或者能贴出解释这个问题的链接．
[ 本帖最后由 yuangong 于
22:39 编辑 ]
&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp
稍有积蓄, 积分 351, 距离下一级还需 149 积分
论坛徽章:0
对socket不用加锁，但对你要用到写缓冲区需要锁定，因为那个是共享资源。
论坛徽章:0
socket描述符就是一个普通的文件描述符吧，和标准输出的情况应该一样的
丰衣足食, 积分 687, 距离下一级还需 313 积分
论坛徽章:0
多个线程操作一个socket，就算加了锁，数据在内核缓冲区也可能会出现交替。
论坛徽章:0
原帖由 diker007 于
00:23 发表
多个线程操作一个socket，就算加了锁，数据在内核缓冲区也可能会出现交替。
恩，向描述符输出了就是写到缓冲区，至于何时将缓冲区内容写出，由内核决定，例如，标准输出，采用行缓冲的话，直到遇到\n或缓冲区满或fflush，才会将缓冲区内容写出，
[ 本帖最后由 cugb_cat 于
09:59 编辑 ]
稍有积蓄, 积分 330, 距离下一级还需 170 积分
论坛徽章:0
那个写缓存为系统资源，如何能对其加锁?
加锁socket是保证每次只有一个线程对其操着,数据在内核缓冲区应该是不会出现交替
大富大贵, 积分 12018, 距离下一级还需 7982 积分
论坛徽章:0
和socket还是普通文件没有关系，因为write的参数是fd,而不是socket特定的
多个线程都要写的有几个特点
1.哪个线程先写是不一定的
2.写可能少于要写的字节
很显然，内核不负责，可能出现这种情况
a线程写100个字节，结果返回80，然后到用户态了，最后b线程又写，写成功了若干字节。
稍有积蓄, 积分 449, 距离下一级还需 51 积分
论坛徽章:0
我一般为了保险起见，加上锁的。
我一般为了保险起见，加上锁的。
稍有积蓄, 积分 330, 距离下一级还需 170 积分
论坛徽章:0
原帖由 flw2 于
09:31 发表
和socket还是普通文件没有关系，因为write的参数是fd,而不是socket特定的
多个线程都要写的有几个特点
1.哪个线程先写是不一定的
2.写可能少于要写的字节
很显然，内核不负责，可能出现这种情况
a线程写 ...
每个socket都有自己的接收缓存,对socket加锁,也就是说每次write前对其加锁.
这样即使发生切换,缓存也只有一个线程能写.
所以不会发生A写了80字节后切换,B 写了30字节,A又写剩下的20字节.
也就是 说多线程对同一socket进行写,的确需要加锁?
白手起家, 积分 0, 距离下一级还需 200 积分
论坛徽章:0
socket write应该是原子的。
北京皓辰网域网络信息技术有限公司. 版权所有 京ICP证:060528号 北京市公安局海淀分局网监中心备案编号：
广播电视节目制作经营许可证(京) 字第1234号
中国互联网协会会员&&联系我们：
感谢所有关心和支持过ChinaUnix的朋友们
转载本站内容请注明原作者名及出处多线程管理下的数据库访问技术_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
多线程管理下的数据库访问技术
上传于|0|0|暂无简介
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
你可能喜欢多线程操作数据库时为了防止数据的增删改的混乱该在数据库层还是程序层面上进行同步？
来源：csdn
【假设两张表中各有一个字段，是由约束关系的，比如一张表是已经卖出的票的数目，另一张表是还剩余的票的数目。为了操作两张表时保证数据的原子性，应该在数据库层设置还是在程序层做设置？两种方式各有什么优缺点？】
用售票系统来举例
这种问题说明你操作数据层是面向对象的
这样在多线程下会出现剩余票数不一致
这是由于你取数据对象后
还没进行数据操作 其他线程就对数据该条数据操作了 导致你现在纠结的问题
解决方法大致分为两种：
1、利用存储过程，对售票逻辑编写存储过程来保证数据操作的唯一性
2、利用纯SQL语句对售票逻辑进行处理
如： update ticket
restTicket=(restTicket-1)
where.........
上面任何一种方法都适用，不过存储过程编写需要一定的基本功，建议使用第二种，简单明了又能有效解决问题
基本上是数据库层面为主；程序层面的话因为涉及到要如何解决集群问题，所以比较麻烦。
但如果是12306之类的这种压力规模系统，直接把所有事物管控下推数据库可能将数据库变为瓶颈，所以需要特殊设计。
两个字：事务
多几个字：不管你在哪个层面，都要对数据库进行事务处理
锁数据是基本的。
两个字：事务
多几个字：不管你在哪个层面，都要对数据库进行事务处理
锁数据是基本的。
两个字：事务
多几个字：不管你在哪个层面，都要对数据库进行事务处理
锁数据是基本的。
hqshaozhu:
在数据库层面的话就需要通过加锁来控制原子性，事务是无法控制的，因为事务具有隔离性。
举例，现剩余数量是1，有一个线程去读取剩余数据，并进行出票操作，由于这个线程还未提交事务，这时有另一个线程来读取剩余数量，读取到的还是1，所以也进行出票操作，这样就出错了。
如果在应用层面控制的话解决方法可以使用队列，或者加锁并发操作
guixiang155cm:
数据层做悲观锁效率太差，且承载资源有限。
1.简单方案：使用cache实例做同步锁
2.复杂方案：使用zookeeper的分布式锁实现（尽量使用锁分段）
假如操作这2张表库存的方法是 abc(int lessStock)
getLock();
returnLock();
Javainging:
数据库事务，怎可能会在程序中控制呢
数据库事务是一种层次，而且这也是需要应用程序显式声明两个sql操作在同一个事务中的。（不知道在应用程序中事务的，就不提了）。
但是能够在内存操作中考虑到需要“原子”操作的，（假设能够用在大系统中的话）是另外一个层次。因为内存操作毕竟会比数据库操作快100倍速度的！
将很关键、很简单的原则操作放在多步业务流程的“最开头”，然后后边的操作就可以尽量异步处理（并且也尽量不加锁）了。而如果你把“修改库存票数”这个操作放在多步业务流程的最后，那么你就会写出一个冗长、严重阻塞整体性能的程序。
将很关键、很简单的原则操作放在多步业务流程的“最开头” -> 将很关键、很简单的原子操作放在多步业务流程的“最开头”
如果你说“程序层做设置”，它不是还是得修改数据库嘛！
正因为此，有些人很懒，觉得既然一切最终都要记录到数据库，那么干脆就用存储过程写业务逻辑程序就得了。而人家用程序显式地声明事务（将两条update语句封装在一个事务的begin/commit之间），就被他看作是非要辨出个是非曲直的多大事儿出来。
实际上如果不考虑效率，那么程序员随便折腾程序。谁跟老板是亲戚，谁说的就是对的。但是考虑性能需求，用较少的成本产生足以打败竞争对手的高性能、高并发处理能力的需求，这就能分出哪种设计才是更加值得鼓励的了！
这个事务描述是错误的！一般默认的隔离级别，通常是可以避免幻象读问题的。（更何况还可以自定义更严格级别）
当一个事务读取剩余数量1、而并没有结束出票操作时，另外一个线程启动的事务就不能读取到剩余数量（也就是不能读取到1）。所以这里所谓的“出错”不成立！
在数据库层还是程序层，一般情况下取决于你当前框架的支持。
如果没有任何支持，数据库事务是最佳选择，虽然可能存在性能问题。
如果有成熟的缓存架构支持，那么程序层面的处理优势是绝对毋庸置疑的。
免责声明：本站部分内容、图片、文字、视频等来自于互联网，仅供大家学习与交流。相关内容如涉嫌侵犯您的知识产权或其他合法权益，请向本站发送有效通知，我们会及时处理。反馈邮箱&&&&。
学生服务号
在线咨询，奖学金返现，名师点评，等你来互动}