并发求助

Kingofcode 2016-10-09 04:35:56
本人技术菜,现公司项目原创人员都已不在,项目虽然上线很久了但是一个问题一直解决不了,没办法技术菜,另外几个同事也是。系统本身是采用C# MVC模式 做的管理项目,由于数据结构设计的比较复杂所以在一些模块某些操作上反应较慢就会报错。如果用的人少 出错的情况基本不会出现,所以我们判断可能是并发的原因,想请教一下比如我一个保存的操作

Public ClassName Save(Class Name,FormCollection collection)
{
_save(...)
{
}
}

我想问的是 比如保存这里容易报错,那么如果使用多线程互斥锁的方式 最简单的例子应该如何写
求教,从未用过多线程 用户大概几百人的样子
多谢多谢
...全文
523 16 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
16 条回复
切换为时间正序
请发表友善的回复…
发表回复
Kingofcode 2016-10-11
  • 打赏
  • 举报
回复
感觉还是在纯粹的软件公司好些 有问题不止于很无助 以前都是做C/S的 没做过B/S的 现在B/S的东西 一会报错 一会没有 服务器报错 本机没有 又难以重现 真是头大
编程有钱人了 2016-10-11
  • 打赏
  • 举报
回复
如果实在想不通 就用数据库锁 省事
圣殿骑士18 2016-10-11
  • 打赏
  • 举报
回复
使用lock会导致用户使用排队,用户感觉系统变慢。是忍受系统变慢,还是忍受系统出错,没有两全方案。 可以考虑优化一下你的数据库,还有改进一下代码中的不合理事务
闭包客 2016-10-10
  • 打赏
  • 举报
回复
如果简单粗暴一点,还可以把连接字符串的隔离模式、数据库的隔离模式都调到 Serializable 串行化隔离。
Kingofcode 2016-10-10
  • 打赏
  • 举报
回复
引用 10 楼 sp1234 的回复:
互斥就是那样使用一个 标志 object 即可。 对于后果,我给你打个比方吧:假设一个仓储式超市有40个收银台同时工作,才能保证顾客基本上能够仅排很短的队伍(不超过10个人)而有序地结账。你现在因为技术不行,一个收银台干完活儿之后就关闭了,然后让另外一个收银台才开放........想想后果。
郁闷 我也是小兵 我们就几个人 现在莫名其妙就落到我头上 领导也不懂技术 连个请教指导的人都没有 感觉好没意思 也不是耍滑头的人 解决不了 总感觉不自在
dp517849241 2016-10-10
  • 打赏
  • 举报
回复
几百人就并发????
  • 打赏
  • 举报
回复
互斥就是那样使用一个 标志 object 即可。 对于后果,我给你打个比方吧:假设一个仓储式超市有40个收银台同时工作,才能保证顾客基本上能够仅排很短的队伍(不超过10个人)而有序地结账。你现在因为技术不行,一个收银台干完活儿之后就关闭了,然后让另外一个收银台才开放........想想后果。
qq_28023843 2016-10-09
  • 打赏
  • 举报
回复
都不管 定义一个全局的静态资源 使用lock加锁这个资源就行了 , 只要资源是相同的 那么就会加锁 ,当然不同的方法就不能使用同一资源了 。。 比如你的save跟upate .. 如果你传递的参数中有在该方法里始终不变的 也可以使用它来作为资源
Kingofcode 2016-10-09
  • 打赏
  • 举报
回复
我们怀疑 报错的原因在于 比如用户A保存001这个单 保存动作由于耗时尚未完成 然后又点了其他的 或者用户B又来保存002这个单才报错 那么我的这个TheLock 应该如何定义 需要复制吗 还是传参 什么的
引用 6 楼 closurer 的回复:
定义一个静态变量:

public static object TheLock;

lock(TheLock)
{
    //这里调用 save 函数
}
Kingofcode 2016-10-09
  • 打赏
  • 举报
回复
引用 5 楼 qq_28023843 的回复:
写错了 lock(obj) 是共享资源的对象 同一对象才会加锁
还是一脸懵逼,糊涂得很 郁闷 我们的项目就是MVC的 拿保存做例子 里面参数主要有要保存的对象 还有其他的 那我要如何做?
闭包客 2016-10-09
  • 打赏
  • 举报
回复
定义一个静态变量:

public static object TheLock;

lock(TheLock)
{
    //这里调用 save 函数
}
qq_28023843 2016-10-09
  • 打赏
  • 举报
回复
写错了 lock(obj) 是共享资源的对象 同一对象才会加锁
Kingofcode 2016-10-09
  • 打赏
  • 举报
回复
引用 3 楼 qq_28023843 的回复:
//共享资源 private static object obj = new object(); Public ClassName Save(Class Name,FormCollection collection) { lock(object){ _save(...) { } } }
这个objece就是这样写 还是说和我的业务有关联的
qq_28023843 2016-10-09
  • 打赏
  • 举报
回复
//共享资源 private static object obj = new object(); Public ClassName Save(Class Name,FormCollection collection) { lock(object){ _save(...) { } } }
Kingofcode 2016-10-09
  • 打赏
  • 举报
回复
引用 1 楼 qq_28023843 的回复:
可以使用加锁。。。
真心不知道如何写,可以帮忙修改一下看看吗
qq_28023843 2016-10-09
  • 打赏
  • 举报
回复
可以使用加锁。。。
整理的高性能高并发服务器架构文章,内容预览:  初创网站与开源软件 6  谈谈大型高负载网站服务器的优化心得! 8  Lighttpd+Squid+Apache搭建高效率Web服务器 9  浏览量比较大的网站应该从哪几个方面入手? 17  用负载均衡技术建设高负载站点 20  大型网站的架构设计问题 25  开源平台的高并发集群思考 26  大型、高负载网站架构和应用初探 时间:30-45分钟 27  说说大型高并发高负载网站的系统架构 28  mixi技术架构 51 mixi.jp:使用开源软件搭建的可扩展SNS网站 51 总概关键点: 51 1,Mysql 切分,采用Innodb运行 52 2,动态Cache 服务器 -- 52 美国Facebok.com,中国Yeejee.com,日本mixi.jp均采用开源分布式缓存服务器Memcache 52 3,图片缓存和加 52  memcached+squid+apache deflate解决网站大访问量问题 52  FeedBurner:基于MySQL和JAVA的可扩展Web应用 53  YouTube 的架构扩展 55  了解一下 Technorati 的后台数据库架构 57  Myspace架构历程 58  eBay 的数据量 64  eBay 的应用服务器规模 67  eBay 的数据库分布扩展架构 68  从LiveJournal后台发展看大规模网站性能优化方法 70 一、LiveJournal发展历程 70 二、LiveJournal架构现状概况 70 三、从LiveJournal发展中学习 71 1、一台服务器 71 2、两台服务器 72 3、四台服务器 73 4、五台服务器 73 5、更多服务器 74 6、现在我们在哪里: 75 7、现在我们在哪里 78 8、现在我们在哪里 79 9、缓存 80 10、Web访问负载均衡 80 11、MogileFS 81  Craigslist 的数据库架构 81  Second Life 的数据拾零 82  eBay架构的思想金矿 84  一天十亿次的访问-eBay架构(一) 85  七种缓存使用武器 为网站应用和访问加速发布时间: 92  可缓存的CMS系统设计 93  开发大型高负载类网站应用的几个要点 105  Memcached和Lucene笔记 110  使用开源软件,设计高性能可扩展网站 110  面向高负载的架构Lighttpd+PHP(FastCGI)+Memcached+Squid 113  思考高并发高负载网站的系统架构 113  "我在SOHU这几年做的一些门户级别的程序系统(C/C++开发)" 115  中国顶级门户网站架构分析1 116  中国顶级门户网站架构分析 2 118  服务器的大用户量的承载方案 120  YouTube Scalability Talk 121  High Performance Web Sites by Nate Koechley 123 One dozen rules for faster pages 123 Why talk about performance? 123 Case Studies 124 Conclusion 124  Rules for High Performance Web Sites 124  对于应用高并发,DB千万级数量该如何设计系统哪? 125  高性能服务器设计 130  优势与应用:再谈CDN镜像加速技术 131  除了程序设计优化,zend+ eacc(memcached)外,有什么办法能提高服务器的负载能力呢? 135  如何规划您的大型JAVA多并发服务器程序 139  如何架构一个“Just so so”的网站? 148  最便宜的高负载网站架构 152  负载均衡技术全攻略 154  海量数据处理分析 164  一个很有意义的SQL的优化过程(一个电子化支局中的大数据量的统计SQL) 166  如何优化大数据量模糊查询(架构,数据库设置,SQL..) 168  求助:海量数据处理方法 169 # re: 求助:海量数据处理方法 回复 更多评论 169  海量数据库查询方略 169  SQL Server 2005对海量数据处理 170  分表处理设计思想和实现 174  Linux系统高负载 MySQL数据库彻底优化(1) 179  大型数据库的设计与编程技巧 本人最近开发一个访问统计系统,日志非常的大,都保存在数据库里面。 我现在按照常规的设计方法对表进行设计,已经出现了查询非常缓慢地情形。 大家对于这种情况如何来设计数据库呢?把一个表分成多个表么?那么查询和插入数据库又有什么技巧呢? 谢谢,村里面的兄弟们! 183  方案探讨,关于工程中数据库的问题. 184  web软件设计时考虑你的性能解决方案 190  大型Java Web系统服务器选型问题探讨 193  高并发高流量网站架构 210 1.1 互联网的发展 210 1.2 互联网网站建设的新趋势 210 1.3 新浪播客的简介 211 2.1 镜像网站技术 211 2.2 CDN内容分发网络 213 2.3 应用层分布式设计 214 2.4 网络层架构小结 214 3.1 第四层交换简介 214 3.2 硬件实现 215 3.3 软件实现 215  网站架构的高性能和可扩展性 233  资料收集:高并发 高性能 高扩展性 Web 2.0 站点架构设计及优化策略 243  CommunityServer性能问题浅析 250 鸡肋式的多站点支持 250 内容数据的集中式存储 250 过于依赖缓存 250 CCS的雪上加霜 250 如何解决? 251  Digg PHP's Scalability and Performance 251  YouTube Architecture 253 Information Sources 254 Platform 254 What's Inside? 254 The Stats 254 Recipe for handling rapid growth 255 Web Servers 255 Video Serving 256 Serving Video Key Points 257 Serving Thumbnails 257 Databases 258 Data Center Strategy 259 Lessons Learned 260 1. Jesse • Comments (78) • April 10th 261 Library 266 Friendster Architecture 273 Information Sources 274 Platform 274 What's Inside? 274 Lessons Learned 274  Feedblendr Architecture - Using EC2 to Scale 275 The Platform 276 The Stats 276 The Architecture 276 Lesson Learned 277 Related Articles 278 Comments 279 Re: Feedblendr Architecture - Using EC2 to Scale 279 Re: Feedblendr Architecture - Using EC2 to Scale 279 Re: Feedblendr Architecture - Using EC2 to Scale 280  PlentyOfFish Architecture 281 Information Sources 282 The Platform 282 The Stats 282 What's Inside 283 Lessons Learned 286  Wikimedia architecture 288 Information Sources 288 Platform 288 The Stats 289 The Architecture 289 Lessons Learned 291  Scaling Early Stage Startups 292 Information Sources 293 The Platform 293 The Architecture 293 Lessons Learned 294  Database parallelism choices greatly impact scalability 295  Introduction to Distributed System Design 297 Table of Contents 297 Audience and Pre-Requisites 298 The Basics 298 So How Is It Done? 301 Remote Procedure Calls 305 Some Distributed Design Principles 307 Exercises 308 References 309  Flickr Architecture 309 Information Sources 309 Platform 310 The Stats 310 The Architecture 311 Lessons Learned 316 Comments 318 How to store images? 318 RE: How to store images? 318  Amazon Architecture 319 Information Sources 319 Platform 320 The Stats 320 The Architecture 320 Lessons Learned 324 Comments 329 Jeff.. Bazos? 329 Werner Vogels, the CTO of 329 Re: Amazon Architecture 330 Re: Amazon Architecture 330 Re: Amazon Architecture 330 It's WSDL 330 Re: It's WSDL 331 Re: Amazon Architecture 331  Scaling Twitter: Making Twitter 10000 Percent Faster 331 Information Sources 332 The Platform 332 The Stats 333 The Architecture 333 L

62,248

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

试试用AI创作助手写篇文章吧