1700449569
1700449570
这里的关键是本地方法start0，它实现了启动线程、申请栈内存、运行run方法、修改线程状态等职责，线程管理和栈内存管理都是由JVM负责的，如果覆盖了start方法，也就是撤消了线程管理和栈内存管理的能力，这样如何启动一个线程呢？事实上，不需要关注线程和栈内存的管理，只需要编码者实现多线程的逻辑即可（即run方法体），这也是JVM比较聪明的地方，简化多线程应用。
1700449571
1700449572
那可能有读者要问了：如果确实有必要覆写start方法，那该如何处理呢？这确实是一个罕见的要求，不过，要覆写也很容易，只要在start方法中加上super.start即可，代码如下：
1700449573
1700449574
class MultiThread extends Thread{
1700449575
1700449576
@Override
1700449577
1700449578
public void start（）{
1700449579
1700449580
/*线程启动前的业务处理*/
1700449581
1700449582
super.start（）；
1700449583
1700449584
/*线程启动后的业务处理*/
1700449585
1700449586
}
1700449587
1700449588
@Override
1700449589
1700449590
public void run（）{
1700449591
1700449592
//MultiThread do something.
1700449593
1700449594
}
1700449595
1700449596
}
1700449597
1700449598
注意看start方法，调用了父类的start方法，没有主动调用run方法，这是由JVM自行调用的，不用我们显式实现，而且是一定不能实现。此方式虽然解决了“覆写start方法”的问题，但是基本上无用武之地，到目前为止还没有发现一定要覆写start方法的多线程应用，所有要求覆写start的场景，都可以用其他的方式来实现，例如类变量、事件机制、监听等方式。
1700449599
1700449600
注意 继承自Thread类的多线程类不必覆写start方法。
1700449601
1700449602
1700449603
1700449604
1700449606
编写高质量代码：改善Java程序的151个建议 建议119：启动线程前stop方法是不可靠的
1700449607
1700449608
有这样一个案例，我们需要一个高效率的垃圾邮件制造机，也就是需要有尽可能多的线程来尽可能多地制造垃圾邮件，垃圾邮件需要的信息保存在数据库中，如收件地址、混淆后的标题、反垃圾处理后的内容等，垃圾制造机的作用就是从数据库中读取这些信息，判断是否符合条件（如收件地址必须包含@符号、标题不能为空等），然后转换成一份真实的邮件发送出去。
1700449609
1700449610
整个应用逻辑很简单，这必然是一个多线程的应用，垃圾邮件制造机需要继承Thread类，代码如下：
1700449611
1700449612
//垃圾邮件制造机
1700449613
1700449614
class SpamMachine extends Thread{
1700449615
1700449616
@Override
1700449617
1700449618
public void run（）{
[
上一页 ]
[ :1.700449569e+09 ]
[
下一页 ]