线程

1、实现线程的两种方式 （1）继承Thread类 　　Thread构造方法：public Thread(String threadName) 　　　　　　　　　　 public Tread() 　　重写run（）方法，并调用start（）执行线程。 　　语法：public static void main(String [] args){ 　　　　　　　　new ThreadTest().start(); 　　　　　　} （2）实现Runnable接口 　　语法：public class Thread extends Object implements Runnable 　　实现Runnable接口会创建Thread对象，并将Runnable对象和Thread对象相关联。 　　Thread构造方法：public Thread（Runnable r） 　　　　　　　　　　 public Thread(Runnable r,String name) 　　步骤：1)建立Runnable对象 　　　　　2）使用参数为Runnable对象的构造方法创建Thread实例。 　　　　　3）调用start（）方法启动线程。 　　创建Runnable对象：编写一个实现Runnable接口的类，然后实例化该类的对象。 2、线程的生命周期 （1）出生状态：调用start（）前 （2）就绪状态

区别：调用start方法实现多线程，而调用run方法没有实现多线程 Start: 用start方法来启动线程，真正实现了多线程运行，这时无需等待run方法体代码执行完毕而直接继续执行下面的代码。通过调用Thread类的start()方法来启动一个线程，这时此线程处于就绪（可运行）状态， 并没有运行，一旦得到cpu时间，就开始执行run()方法 ，这里方法run()称为线程体，它包含了要执行的这个线程的内容，Run方法运行结束，此线程随即终止。 Run: run()方法只是类的一个普通方法而已，如果直接调用Run方法，程序中依然只有主线程这一个线程，其程序执行路径还是只有一条，还是要顺序执行，还是要等待run方法体执行完毕后才可继续执行下面的代码，这样就没有达到写线程的目的。 总结：调用start方法方可启动线程，而run方法只是thread的一个普通方法调用，还是在主线程里执行。 来源： https://www.cnblogs.com/LinuxJames/archive/2013/01/18/2865651.html

数据同步需要依赖锁，那锁的同步又依赖谁？synchronized给出的答案是在软件层面依赖JVM，而Lock给出的方案是在硬件层面依赖特殊的CPU指令，大家可能会进一步追问：JVM底层又是如何实现synchronized的？ 本文所指说的JVM是指Hotspot的6u23版本，下面首先介绍synchronized的实现： synrhronized关键字简洁、清晰、语义明确，因此即使有了Lock接口，使用的还是非常广泛。其应用层的语义是可以把任何一个非null 对象 作为"锁"，当synchronized作用在方法上时，锁住的便是对象实例（this）；当作用在静态方法时锁住的便是对象对应的Class实例，因为 Class数据存在于永久带，因此静态方法锁相当于该类的一个全局锁；当synchronized作用于某一个对象实例时，锁住的便是对应的代码块。在 HotSpot JVM实现中，锁有个专门的名字：对象监视器。 1. 线程状态及状态转换 当多个线程同时请求某个对象监视器时，对象监视器会设置几种状态用来区分请求的线程： Contention List：所有请求锁的线程将被首先放置到该竞争队列 Entry List：Contention List中那些有资格成为候选人的线程被移到Entry List Wait Set：那些调用wait方法被阻塞的线程被放置到Wait Set OnDeck

线程的一个关键特性是每个线程都是独立运行且状态不可预测。 如果程序中的其他线程需要通过判断某个线程的状态来确定自己下一步的操作,这时我们需要使用threading库中的Event对象。 event.set（）：设置事件状态为True event.wait （）：等待event.set 把事件状态设置为True event.is_set（）：检查事件状态是否为True #事件 from threading import Thread,current_thread,Event import threading import time,random def conn_mysql(): count=1 while not event.is_set(): if count>2: break print("%s 第%s次 尝试链接" %(current_thread().getName(),count)) event.wait(0.1) count+=1 print("%s 第%s次 链接成功" %(current_thread().getName(),count)) def check_mysql(): print("%s 正在检查mysql"%current_thread().getName()) time.sleep(random.randint(1,2)) event.set() if

在上篇文章中我们已经知道了多线程是什么了，那么它到底可以干嘛呢？这里特别声明一个前面的委托没看的同学可以到上上上篇博文查看，因为多线程要经常使用到 委托 。 源码 一、异步、同步 1.同步（在计算的理解总是要你措不及防，同步当线程做完一件事情之后，才会执行后续动作），同步方法慢，只有一个线程执行，异步方法快，因为多个线程一起干活，但是两者并不是线性增长，当我们的异步线程占有的资源越来越多了，会导致资源可能不够，其次线程过多CPU也是需要管理成本的，所以不是越多越好。 2.异步（可以同时执行多个任务，在同样的时间，执行不同的任务），同步方法卡界面（UI）,因为我们的主线程（UI）忙于计算造成了堵塞了。异步方法不卡界面，计算任务交给了子线程完成。winform中体现的玲玲精致。（你品，你细品），web 可以异步的处理一起其他的任务,比如给用户发邮箱（我们的BS结构的，每次访问都是一个子线程，当我们的代码写的比较糟糕，是不是加载比较慢呢哈哈）。异步多线程无序，执行的先后无序，执行的时间不确定，结束也不确定，所以我们很难通过执行时间和先后顺序控制，异步的执行顺序。 二、初识Thread 属性名称 说明 CurrentContext 获取线程正在其中执行的当前上下文。 CurrentThread 获取当前正在运行的线程。 ExecutionContext 获取一个

本文是 golang 实现 redis 系列的第三篇, 主要介绍如何实现内存KV数据库。本文完整源代码在作者Github: HDT3213/godis db.go 是内存数据库的主要源文件，db.Exec 方法会从协议解析器中获得命令参数并调用相应的处理函数进行处理。 目录: Concurrent Hash Map LockMap TTL Concurrent Hash Map KV 内存数据库的核心是并发安全的哈希表，常见的设计有几种： sync.map: golang 官方提供的并发哈希表, 性能优秀但结构复杂不便于扩展 juc.ConcurrentHashMap: java 的并发哈希表采用分段锁实现。在进行扩容时访问哈希表线程都将协助进行 rehash 操作，在 rehash 结束前所有的读写操作都会阻塞。因为缓存数据库中键值对数量巨大且对读写操作响应时间要求较高，使用juc的策略是不合适的。 memcached hashtable: 在后台线程进行 rehash 操作时，主线程会判断要访问的哈希槽是否已被 rehash 从而决定操作 old_hashtable 还是操作 primary_hashtable。 这种策略使主线程和rehash线程之间的竞争限制在哈希槽内，最小化rehash操作对读写操作的影响，这是最理想的实现方式。但由于作者才疏学浅无法使用 golang

一：并发编程 + activemq + 实战案例并发编程基础篇 第一天 1、课程大纲简要介绍 2、线程基础概念、线程安全概念、多个线程多个锁概念 3、对象锁的同步和异步 4、脏读概念、脏读业务场景、Synchronized概念、Synchronized代码块、Synchronized其他细节 微云学习地址：文件分享 网盘学习地址：https://pan.baidu.com/s/1CTx5SqUeM-ZKtDYLeovODQ 提取码：iclq 微云学习地址：文件分享 致学者：不论你在什么时候开始，重要的是开始之后请不要停止。 第二天 1、Volatile关键字概念、线程优化执行流程、内部原理讲解 2、Volatile关键字的非原子性 3、并发编程下的多线程间通信概念wait、notify，线程经典面试题讲解 4、模拟底层阻塞队列（queue）实现讲解 5、单例和多线程如何结合使用并发编程中级篇 第三天 1、同步类容器讲解 2、并发类容器讲解 3、Concurrent集合类讲解与底层原理实现 4、CopyOnWrite集合类讲解与底层原理实现 5、各类并发Queue详细讲解 第四天 1、多线程设计模式之Future模式讲解与模拟实现 2、多线程设计模式之Master-Worker模式讲解与模拟实现 3、多线程设计模式之生产消费者模型讲解与模拟实现并发编程高级篇 第五天 1

erlang多进程与多线程： 在erlang开发中，我们面对的最小执行单位是进程，当然这个进程并不是系统层面上的进程，也不是线程。而是基于erlang运行时系统的一个进程。那么erlang的多进程是如何变成系统级别上的多线程，进而被多核处理器处理呢？ 其实，我们每启动一个erlang VM，实际上就启动了模拟器+erlang运行时系统。而每个erlang运行时系统会启动N个进程调度器，每个进程调度器都是一个独立的操作系统线程。这个调度器会处理一个进程池，进程池里面是M个erlang进程。也就是说erlang进程以1:M的方式映射到操作系统线程。 既然每个调度器都是一个操作系统线程，那么可并行运行的erlang进程最多就能有M个。虽然一个进程池内有M个进程，但是同一池内的进程仍像之前所有进程公用一个调度器那样分时运行。 并且在此之上，进程可以在进程池之间迁移以便维持可用调度器上的负载均衡。 erlang程序的单进程与多线程： 每启动一个erlang VM，也就启动了一个进程，该进程包括很多线程，最基本就包括了erlang运行时系统和模拟器所创建的线程。如果在该虚拟机上还运行erlang程序，那么ERTS就有可能为你的应用程序创建了N个线程。这些线程的个数，跟启动erlang VM时设置的参数和自身硬件环境有关

时钟中断是操作系统最重要的中断，操作系统内核依靠时钟中断完成时间片计算和分配、定时等管理工作，是分时机制实现的基础。可以说如果没有时钟中断，操作系统将无法正常运行。时钟中断由专门的时钟芯片产生，比如PC机上的8253芯片。大多数的操作系统实现，时钟中断周期会维持在10ms到100ms之间，比如Windows操作系统，其时钟中断周期一般为10ms或者20ms。表面上看，似乎时钟中断周期越短，系统的实时性越好，因为进程或线程的运行时间片会被控制的越精确，优先级高的进程或线程会优先得到运行。但仔细分析起来，会发现实际并不是这么回事，时钟中断周期的大小与系统整体实时性关系并不十分紧密。 可用两个指标来衡量操作系统的实时性：一个是中断响应时间，即从外部中断发生，到得到操作系统处理之间的时间；另外一个是任务切入时间，即一个高优先级的线程运行所需的资源就绪，到得到调度所需的时间。时钟中断周期的大小，与这两个指标并无直接关联。 首先看中断响应时间，这个时间与硬件系统关联紧密。中断一般由外部设备引发，外部设备的控制电路连接到计算机的中断控制器上（比如PC的8259A芯片）。一旦外部设备发生中断，设备会通过一条中断引脚通知中断控制器，中断控制器根据输入引脚的状态（比如是否禁止引发中断）、输入引脚的优先级、连接到片上的其它中断引脚的情况，综合判断是否需要对该中断进行处理。如果判断结果为进一步处理

MainActivity如下: package cc.c; import android.app.Activity; import android.os.Bundle; import android.os.Handler; import android.os.Looper; import android.os.Message; import android.widget.TextView; /** * Demo描述: * * 示例步骤如下: * 1 子线程给子线程本身发送消息 * 2 收到1的消息后,子线程给主线程发送消息 * 3 收到2的消息后,主线程给子线程发送消息 * * 为实现子线程给自己本身发送消息,关键还是在于构造Handler时传入的Looper. * 在此就传入该子线程自己的Looper即调用Looper.myLooper(),代码如下: * Looper.prepare(); * mHandlerTest1=new HandlerTest1(Looper.myLooper()); * Looper.loop(); * * 所以当mHandlerTest1.sendMessage(message);发送消息时 * 当然是发送到了它自己的消息队列. * * 当子线程中收到自己发送的消息后,可继续发送消息到主线程.此时只要注意构造 *