上一页 1 ··· 5 6 7 8 9 10 11 12 13 14 下一页
摘要: 建议81:使用Parallel简化同步状态下Task的使用在命名空间System.Threading.Tasks中,有一个静态类Parallel简化了在同步状态下的Task的操作。Parallel主要提供3个有用的方法:For、ForEach、Invoke。For方法主要用于处理针对数组元素的并行操... 阅读全文
posted @ 2015-08-19 17:15 JesseLZJ 阅读(334) 评论(0) 推荐(0) 编辑
摘要: 建议80:用Task代替ThreadPool ThreadPool相对于Thread来说具有很多优势,但是ThreadPool在使用上却存在一定的不方便。比如:ThreadPool不支持线程的取消、完成、失败通知等交互性操作。ThreadPool不支持线程执行的先后次序。以往,如果开发者要实现上述功... 阅读全文
posted @ 2015-08-19 17:11 JesseLZJ 阅读(453) 评论(0) 推荐(0) 编辑
摘要: 建议79:使用ThreadPool或BackgroundWorker代替Thread使用线程能极大地提升用户体验度,但是作为开发者应该注意到,线程的开销是很大的。线程的空间开销来自:1)线程内核对象(Thread Kernel Object)。每个线程都会创建一个这样的对象,它主要包含线程上下文信息... 阅读全文
posted @ 2015-08-19 16:35 JesseLZJ 阅读(618) 评论(0) 推荐(0) 编辑
摘要: 建议78:应避免线程数量过多在多数情况下,创建过多的线程意味着应用程序的架构设计可能存在着缺陷。经常有人会问,一个应用程序中到底含有多少线程才是合理的。现在我们找一台PC机,打开Windows的任务管理器,看看操作系统中正在运行的程序有多少个线程。在笔者当前的PC机上,线程数最多的一个应用程序是某款... 阅读全文
posted @ 2015-08-19 16:21 JesseLZJ 阅读(619) 评论(0) 推荐(0) 编辑
摘要: 建议77: 正确停止线程开发者总尝试对自己的代码有更多的控制。例如,“让那个还在工作的线程马上停止下来”。然而,并非我们想怎样就可以怎样的,这至少涉及两个问题。第一个问题 正如线程不能立即启动一样,线程也并不是说停就停的。无论采用何种方式通知工作线程需要停止,工作线程都会忙完手头最紧要的活,然后在它... 阅读全文
posted @ 2015-08-19 15:38 JesseLZJ 阅读(532) 评论(2) 推荐(0) 编辑
摘要: 建议76: 警惕线程的优先级线程在C#中有5个优先级:Highest、AboveNormal、Normal、BelowNormal和Lowest。讲到线程的优先级,就会涉及线程的调度。Windows系统是一个基于优先级的抢占式调度系统。在系统中,如果有一个线程的优先级较高,并且它正好处在就绪状态,系... 阅读全文
posted @ 2015-08-19 15:31 JesseLZJ 阅读(387) 评论(0) 推荐(0) 编辑
摘要: 建议75:警惕线程不会立即启动现代的大多数操作系统都不是一个实时的操作系统,Windows系统也是如此。所以,不能奢望我们的线程能够立即启动。Windows内部会实现特殊的算法以进行线程之间的调度,在某个具体的时刻,它会决定当前应该运行哪个线程。这反映到最底层就是某个线程分配到了一定的CPU时间,可... 阅读全文
posted @ 2015-08-19 15:27 JesseLZJ 阅读(294) 评论(0) 推荐(0) 编辑
摘要: 建议74:警惕线程的IsBackground在CLR中,线程分为前台线程和后台线程,即每个线程都有一个IsBackground属性。两者在表现形式上的唯一区别是:如果前台线程不退出,应用程序的进程就会一直存在,必须所有的前台线程全部退出,应用程序才算退出。而后台进程则没有这方面的限制,如果应用程序退... 阅读全文
posted @ 2015-08-19 15:12 JesseLZJ 阅读(401) 评论(0) 推荐(0) 编辑
摘要: 建议73:避免锁定不恰当的同步对象在C#中,让线程同步的另一种编码方式就是使用线程锁。线程锁的原理,就是锁住一个资源,使得应用程序在此刻只有一个线程访问该资源。通俗地讲,就是让多线程变成单线程。在C#中,可以将被锁定的资源理解成new出来的普通CLR对象。既然需要锁定的资源就是C#中的一个对象,我们... 阅读全文
posted @ 2015-08-19 15:07 JesseLZJ 阅读(329) 评论(0) 推荐(0) 编辑
摘要: 建议72:在线程同步中使用信号量所谓线程同步,就是多个线程在某个对象上执行等待(也可理解为锁定该对象),直到该对象被解除锁定。C#中对象的类型分为引用类型和值类型。CLR在这两种类型上的等待是不一样的。我们可以简单地理解为在CLR中,值类型是不能被锁定的,即不能在一个值类型对象上执行等待。而在引用类... 阅读全文
posted @ 2015-08-19 13:26 JesseLZJ 阅读(326) 评论(0) 推荐(0) 编辑
摘要: 建议71:区分异步和多线程应用场景初学者有时候会将异步和多线程混为一谈。如果对它们之间的区别不是很清楚,很容易写出下面这样的代码:private void buttonGetPage_Click(object sender, EventArgs e) { Thread t = new T... 阅读全文
posted @ 2015-08-19 13:01 JesseLZJ 阅读(537) 评论(0) 推荐(0) 编辑
摘要: 建议70:避免在调用栈较低的位置记录异常并不是所有的异常都要被记录到日志,一类情况是异常发生的场景需要被记录,还有一类就是未被捕获的异常。未被捕获的异常通常被视为一个Bug,所以,对于它的记录,应该被视为系统的一个重要组成部分。最适合记录异常和报告的是应用程序的最上层,这通常是UI层。假设存在这样一... 阅读全文
posted @ 2015-08-18 13:28 JesseLZJ 阅读(342) 评论(1) 推荐(0) 编辑
摘要: 建议69:应使用finally避免资源泄漏除非发生让应用程序中断的异常,否则finally总是会先于return执行。finally的这个语言特性决定了资源释放的最佳位置就是在finally块中;另外,资源释放会随着调用堆栈由下往上执行。下面的代码验证了这一点,先定义一个需要释放的类: cla... 阅读全文
posted @ 2015-08-18 12:48 JesseLZJ 阅读(359) 评论(0) 推荐(0) 编辑
摘要: 建议68:从System.Exception或其他常见的基本异常中派生异常微软建议:从System.Exception或其他常见基本异常之一派生异常。在Visual Studio中输入Exception,然后按快捷键Tab,VS会自动创建一个自定义异常类: [Serializable] ... 阅读全文
posted @ 2015-08-18 12:22 JesseLZJ 阅读(441) 评论(0) 推荐(0) 编辑
摘要: 建议67:慎用自定义异常除非有充分的理由,否则不要创建自定义异常。如果要对某类程序出错做特殊处理,那就自定义异常。需要自定义异常的理由如下:1)方便测试。通过抛出一个自定义的异常类型实例,我们可以使捕获的代码精确的知道所发生的事情,并以符合的方式进行恢复。2)逻辑包装。自定义异常可以包装多个其他异常... 阅读全文
posted @ 2015-08-18 11:46 JesseLZJ 阅读(357) 评论(0) 推荐(0) 编辑
摘要: 建议66:正确捕获多线程中的异常多线程的异常处理需要采用特殊的方式。一下这种方式会存在问题: try { Thread t = new Thread((ThreadStart)delegate {... 阅读全文
posted @ 2015-08-17 23:16 JesseLZJ 阅读(1102) 评论(0) 推荐(0) 编辑
摘要: 建议65:总是处理未捕获的异常处理为捕获的异常是每个应用程序具备的基本功能,C#在APPDomain提供了UnhandledException事件来接收未捕获到的异常的通知。常见的应用如下: static void Main(string[] args) { ... 阅读全文
posted @ 2015-08-17 21:58 JesseLZJ 阅读(365) 评论(0) 推荐(0) 编辑
摘要: 建议64:为循环增加Tester-Doer模式而不是将try-catch置于循环内如果需要在循环中引发异常,你需要特别注意,应为抛出异常是一个相当影响性能的过程。应该尽量在循环当中对异常发生的一些条件进行判断,然后根据条件进行处理。做个测试: Stopwatch watch =... 阅读全文
posted @ 2015-08-17 21:39 JesseLZJ 阅读(550) 评论(0) 推荐(0) 编辑
摘要: 建议63:避免“吃掉”异常嵌套异常是很危险的行为,一不小心就就会将异常堆栈信息,也就是真正的Bug出处隐藏起来。这还不是最严重的,最严重的就是“吃掉”异常,即捕获,然后不向上层throw。避免“吃掉”异常,并不是说不应该“吃掉”异常,而是这里有个重要原则:该异常可被预见,并且通常情况它不能算是一个B... 阅读全文
posted @ 2015-08-17 21:26 JesseLZJ 阅读(345) 评论(0) 推荐(0) 编辑
摘要: 建议62:避免嵌套异常应该允许异常在调用堆栈上往上传,不要过多的使用catch,然后再throw。过多的使用catch会带来两个问题:1)代码更多了。这看上去好像你根本不知道怎么处理异常,所以你总是不停地catch。2)隐藏了堆栈信息,使你不知道真正发生异常的地方。无故地嵌套是我们应该极力避免的。当... 阅读全文
posted @ 2015-08-17 19:50 JesseLZJ 阅读(381) 评论(0) 推荐(0) 编辑
上一页 1 ··· 5 6 7 8 9 10 11 12 13 14 下一页