win11误删除注册表导致没有任务栏了

win11误删除注册表导致没有任务栏了

答：在任务栏的空白处（也就是没有快捷方式或最小化窗口的地方）模山陆单击鼠标右键—>在d出的任务栏菜单中点选“锁定任务栏”这样任务栏就被锁定了。锁定后的任务栏不会因鼠标 *** 作失误产生的拖拽而到处移动，也不被调整宽度，十分方便。

当然，若需要在任务栏中同时旦顷显示多个最小化窗口，可以将“锁定任唯纳务栏”选项前的对勾去掉。

对各种Go http路由框架的比较， Iris明显胜出，它袭镇尺的性能远远超过其它Golang http路由框架。

但是，在真实的环境中，Iris真的就是最快的Golang http路由框架吗？

Benchmark测试分析

在那篇文章中我使用的是Julien Schmidt的 测试代码,他模拟了静态路由、Github API、Goolge+ API、Parse API的各种情况，因为这些API是知名网站的开放的API，看起来测试挺真实可靠的。

但是，这个测试存在着一个严重的问题，就是Handler的业务逻辑非常的简单，各个框架的handler类似，比如Iris的Handler的实现：

funcirisHandler(_ *iris.Context) {}funcirisHandlerWrite(c *iris.Context) { io.WriteString(c.ResponseWriter, c.Param("name"))}funcirisHandlerTest(c *iris.Context) { io.WriteString(c.ResponseWriter, c.Request.RequestURI)}

几乎没有任何的业务逻辑，最多是往Response中写入一个字符串。

这和生产环境中的情况严重不符!

实际的产品肯定会有一些业务的处理，比如参数的校验，数据的计算，本地文件的读取、远程服务的调用、缓存的读取、数据库的读取和写入等，有些 *** 作可能花费的时间很多，一两个拍高毫秒就可以搞定，有的却很耗时，可能需要几十毫秒，比如：

从一个网络连接中读取数据 写数据到硬盘中 调用其它服务，等待服务结果的返回 ……

这才是我们常用的case,而不是一个简单的写字符串。

因此那个测试框架的Handler还应该加入时间花费的情况。

模拟真实的Handler的情况

我们模拟一下真实的情况，看看Iris框架和Golang内置的Http路由框架的性能如何。

首先使用Iris实现一个Http Server:

packagemainimport("os""strconv""time""github.com/kataras/iris")funcmain() { api := iris.New() api.Get("/rest/hello",func(c *iris.Context) { sleepTime, _ := strconv.Atoi(os.Args[1])ifsleepTime >0{ time.Sleep(time.Duration(sleepTime) * time.Millisecond) } c.Text("Hello world") }) api.Listen(":8080")}

我们可以传递给它一个时间花费的参数sleepTime，模拟这个Handler在处理业务时要花费的时间，它会让处理这个Handler的暂停sleepTime毫秒，如果为0,则不需要暂停，这种情况类似上面的测试。

然后我们使用Go内置的路由功能实现一个Http Server:

packagemainimport("log""net/http""os""strconv""time")// There are some golang RESTful libraries and mux libraries but i use the simplest to test.funcmain() { http.HandleFunc("/rest/hello",func(w http.ResponseWriter, r *http.Request) { sleepTime, _ := strconv.Atoi(os.Args[1])ifsleepTime >0{ time.Sleep(time.Duration(sleepTime) * time.Millisecond) } w.Write([]byte("Hello world")) }) err := http.ListenAndServe(":8080",nil)iferr !=nil{ log.Fatal("ListenAndServe: ", err) }}

编译两个程序进行测试。

1、首旅枝先进行业务逻辑时间花费为0的测试

运行程序 iris 0,然后执行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello进行并发100,持续30秒的测试。

iris的吞吐率为46155 requests/second。

运行程序 gomux 0,然后执行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello进行并发100,持续30秒的测试。

Go内置的路由程序的吞吐率为55944 requests/second。

两者的吞吐量差别不大，iris略差一点

2、然后进行业务逻辑时间花费为10的测试

运行程序 iris 10,然后执行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello进行并发100,持续30秒的测试。

iris的吞吐率为97 requests/second。

运行程序 gomux 10,然后执行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello进行并发100,持续30秒的测试。

Go内置的路由程序的吞吐率为9294 requests/second。

3、最后进行业务逻辑时间花费为1000的测试

这次模拟一个极端的情况，业务处理很慢，处理一个业务需要1秒的时间。

运行程序 iris 1000,然后执行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello进行并发100,持续30秒的测试。

iris的吞吐率为1 requests/second。

运行程序 gomux 1000,然后执行 wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello进行并发100,持续30秒的测试。

Go内置的路由程序的吞吐率为95 requests/second。

可以看到，如果加上业务逻辑的处理时间，Go内置的路由功能要远远好于Iris, 甚至可以说Iris的路由根本无法应用的有业务逻辑的产品中，随着业务逻辑的时间耗费加大，iris的吞吐量急剧下降。

而对于Go的内置路由来说，业务逻辑的时间耗费加大，单个client会等待更长的时间，但是并发量大的网站来说，吞吐率不会下降太多。

比如我们用1000的并发量测试 gomux 10和 gomux 1000。

gomux 10: 吞吐率为47664 gomux 1000: 吞吐率为979

这才是Http网站真实的情况，因为我们要应付的网站的并发量，网站应该支持同时有尽可能多的用户访问，即使单个用户得到返回页面需要上百毫秒也可以接受。

而Iris在业务逻辑的处理时间增大的情况下，无法支持大的吞吐率，即使在并发量很大的情况下(比如1000),吞吐率也很低。

深入了解Go http server的实现

Go http server实现的是每个request对应一个goroutine (goroutine per request), 考虑到Http Keep-Alive的情况，更准确的说是每个连接对应一个goroutine(goroutine per connection)。

因为goroutine是非常轻量级的，不会像Java那样 Thread per request会导致服务器资源不足，无法创建很多的Thread， Golang可以创建足够多的goroutine，所以goroutine per request的方式在Golang中没有问题。而且这还有一个好处，因为request是在一个goroutine中处理的，不必考虑对同一个Request/Response并发读写的问题。

如何查看Handler是在哪一个goroutine中执行的呢?我们需要实现一个函数来获取goroutine的Id:

funcgoID()int{varbuf[64]byte n := runtime.Stack(buf[:], false) idField := strings.Fields(strings.TrimPrefix(string(buf[:n]),"goroutine "))[0] id, err := strconv.Atoi(idField)iferr !=nil{panic(fmt.Sprintf("cannot get goroutine id: %v", err)) }returnid}

然后在handler中打印出当前的goroutine id:

func(c *iris.Context) { fmt.Println(goID()) ……}

和

func(w http.ResponseWriter, r *http.Request) { fmt.Println(goID()) ……}

启动 gomux 0,然后运行 ab -c 5 -n 5 http://localhost:8080/rest/hello测试一下，apache的ab命令使用5个并发并且每个并发两个请求访问服务器。

可以看到服务器的输出：

因为没有指定 -k参数，每个client发送两个请求会创建两个连接。

你可以加上 -k参数，可以看出会有重复的goroutine id出现，表明同一个持久连接会使用同一个goroutine处理。

以上是通过实验验证我们的理论，下面是代码分析。

net/http/server.go的 第2146行 go c.serve()表明，对于一个http连接，会启动一个goroutine:

func(srv *Server) Serve(l net.Listener) error {deferl.Close()iffn := testHookServerServefn !=nil{ fn(srv, l) }vartempDelay time.Duration// how long to sleep on accept failureiferr := srv.setupHTTP2()err !=nil{returnerr }for{ rw, e := l.Accept() …… tempDelay =0 c := srv.newConn(rw) c.setState(c.rwc, StateNew) // before Serve can returngoc.serve() }}

而这个 c.serve方法会从连接中 读取request交由handler处理:

func(c *conn) serve() { ……for{ w, err := c.readRequest() …… req := w.req serverHandler{c.server}.ServeHTTP(w, w.req)ifc.hijacked() {return } w.finishRequest()if!w.shouldReuseConnection() {ifw.requestBodyLimitHit || w.closedRequestBodyEarly() { c.closeWriteAndWait() }return } c.setState(c.rwc, StateIdle) }}

而 ServeHTTP的实现如下，如果没有配置handler或者路由器，则使用缺省的 DefaultServeMux。

func(sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request) { handler := sh.srv.Handlerifhandler ==nil{ handler = DefaultServeMux }ifreq.RequestURI =="*"&&req.Method =="OPTIONS"{ handler = globalOptionsHandler{} } handler.ServeHTTP(rw, req)}

可以看出这里并没有新开goroutine,而是在同一个connection对应的goroutine中执行的。如果试用Keep-Alive,还是在这个connection对应的goroutine中执行。

正如注释中所说的那样：

// HTTP cannot have multiple simultaneous active requests.[*] // Until the server replies to this request, it can't read another, // so we might as well run the handler in this goroutine. // [*] Not strictly true: HTTP pipelining. We could let them all process // in parallel even if their responses need to be serialized. serverHandler{c.server}.ServeHTTP(w, w.req)

因此业务逻辑的时间花费会影响单个goroutine的执行时间，并且反映到客户的浏览器是是延迟时间latency增大了，如果并发量足够多，影响的是系统中的goroutine的数量以及它们的调度，吞吐率不会剧烈影响。

Iris的分析

如果你使用Iris查看每个Handler是使用哪一个goroutine执行的，会发现每个连接也会用不同的goroutine执行，可是性能差在哪儿呢？

或者说,是什么原因导致Iris的性能急剧下降呢？

Iris服务器的监听和为连接启动一个goroutine没有什么明显不同，重要的不同在与Router处理Request的逻辑。

原因在于Iris为了提供性能，缓存了context,对于相同的请求url和method,它会从缓存中使用相同的context。

func(r *MemoryRouter) ServeHTTP(res http.ResponseWriter, req *http.Request) {ifctx := r.cache.GetItem(req.Method, req.URL.Path)ctx !=nil{ ctx.Redo(res, req)return } ctx := r.getStation().pool.Get().(*Context) ctx.Reset(res, req)ifr.processRequest(ctx) {//if something found and served then add it's clone to the cache r.cache.AddItem(req.Method, req.URL.Path, ctx.Clone()) } r.getStation().pool.Put(ctx)}

由于并发量较大的时候，多个client的请求都会进入到上面的 ServeHTTP方法中，导致相同的请求会进入下面的逻辑：

ifctx := r.cache.GetItem(req.Method, req.URL.Path)ctx !=nil{ ctx.Redo(res, req)return}

ctx.Redo(res, req)导致不断循环，直到每个请求处理完毕，将context放回到池子中。

所以对于Iris来说，并发量大的情况下,对于相同的请求(req.URL.Path和Method相同)会进入排队的状态，导致性能低下。

IRIS标准中要求有12个强制性符合项即K.O项，目前根据公司实际情况，设计和开发（公司没有产品设计，但存在产品实现过程设计）过程不属于认证范围：

一、4.1条款----质量管理体系--总要求----如果在合同执行过程中出现转包或部分转包影响产品的符合性时，转包程序是否包括可行性研究、风险分析、策划、顾客沟通，以及进行与现有水品相符的首件鉴定？

注解：外包过程：是经公司识别为质量管理体系所需的，但选择由公司的外部方实施的过程（或活动）。

适用于公司的所有外包/转包过程（包括: 委托外加工产品的外包过枝渗程（如裙板焊接）、委托代理公司的运输外包过程（山东丛林集团车队、龙口市第二运输公司货运车队）、由公司提供计量器具委托具有资质的部门进行校验（龙口市、烟台市计量所）和部分产品的检验或试验过程的外包）。 二、7.3.2条款——组织是否确保满足市场要求的新技术/新产品在应用到顾客项目之前已经过确认？

7.3.6条款——组织是否能确保研发报告、计算、试验结果等数据能够证明产品可以适应所有相关运营情况的规范要求？

注解：我公司目前没有产品的设计和开发，但存在新产品的模具设计、工艺设计，目前腔搭凯已经对新产品、新技术进行了定位，并针对符合定位条件的新产品、新技术的设计进行评审、验证、确认。 三、7.5.2条款----生产和服务提供过程的确认----特殊过程是否根据合同和/或内部要求进行管理？

注解：特殊过程包括：

a）产品质量不能通过后续的测量或监控加以验证的工序；

b）产品质量需进行破坏性试验或采用复杂、昂贵的方法才能测量或只能进行间接监控的工序；

c）该工序产品仅在产品使用或交付后，不合格的质量特性才能暴露出来的工序。

本公司挤压型材生产的关键过程是锯切，特殊过程是熔铸、挤压、时效、热处理、焊接、着色。

对特殊过程，由技术部组织生产、品保对工艺进行评审、验证、确认；

由综合事业部组织相关部门对人员能力进行确认；

由设备部组织相关部门对伍唤设备设施能力进行确认 。

四、7.7条款----项目管理----在某一跨行业团队内，组织是否应用了项目管理或新产品开发过程，阐述项目管理的适用范围，描述职责和权限，将组织的相关职能整合为跨职能小组？此过程的业绩是否适用KPI（关键绩效考核）进行监测？

注解： 项目部负责主持项目的策划、输入、输出、评审、验证和确认全过程的组织、协调和实施；组织首件鉴定工作，负责项目的成本估算及预算、和对外的产品报价。

项目部根据需要组建多功能小组，多功能小组必须包括：项目部、营业部、技术部、供销公司、生产部、品保部、财务部等部门的人员，必要时，邀请顾客和供应商参加。

针对项目过程绩效考核（KPI）由项目部针对每个项目、每个阶段召集多功能小组进行评审、总结，以达到监测的目的。

五、7.7.5条款----质量管理----组织是否能确保有一个过程来管理项目的交付结果？

注解：在整个项目周期中，必须定期执行项目评审，并形成文件。在预先确定的项目阶段／里程碑，必须进行阶段评审，以评估项目的符合性、工作包可交付成果的可使用性，以及授权启动下一阶段。必须建立项目绩效评估，以便通过绩效指标来监控项目进程和效率。

六、7.9条款----首件鉴定----组织能够提供一份程序文件，在新产品首次批量生产或已有产品的重大升级时，规定对其代表性零件的检验、验证、文件和记录要求？以及对生产过程的确认；对以前首件鉴定失效时的更改。

注解：首件鉴定内容主要包括公司新产品生产、变更后产品首件以及采购的新产品首件，变更包括：工艺方法、检测方法、工艺装置、设备等更改，由品保部负责组织相关部门进行首件鉴定。

七、7.10条款----调试/服务客户----在合同要求调试和顾客服务时，组织能否提供一调试和顾客服务过程，包括：对交付后识别出的问题采取措施，包括调查、报告活动，以及对服务信息的措施？

注解：铝业公司没有调试方面的工作，针对服务客户方面，目前已经建立了《生产和服务提供控制程序》，在程序中规定了由营业部/项目部负责产品交付和服务客户，定期对客户进行满意度调查，对相关信息进行汇总后传递到品保、生产等相关部门，针对出现问题也由营业部/项目部组织协调相关部门在规定的时间内进行解决。

八、7.13条款----更改控制----是否规定了确认和审批活动，以确保更改在实施前符合顾客要求 注解：

目前我们已经建立了《更改控制程序》，更改均由各技术部门负责人进行了批准。

九、8.3.1条款----不合格过程控制----组织是否建立、形成文件并保持了一过程，用于管理经营过程变差，包括：

a)在管理过程不合格时，识别、记录和分析变差的根本原因，并采取适当的措施以纠正不合格过程；

b)评估经营管理过程变差是否已经导致产品不合格； c)识别并控制不合格产品； 注解：

1、不合格过程包括：在各类生产活动（挤压、时效、熔铸、热处理等）中人员、设备、材料、法规（工艺要求等）、环境出现偏差，如人员无证上岗、设备在运行过程中是否出现异常，如：松动、大幅震动等情况，不按工艺要求 *** 作、投错料、设备出现故障、环境未达到要求等。 2、发现部门应对上述不合格过程进行整改或要求责任部门进行整改，同时作出纠正措施。 3、针对不合格过程发生时出现的产品应由品保部进行确认，评估是否因不合格过程导致产品不合格。

4、如出现了不合格品，则按照程序文件中《不合格品控制程序》中要求控制不合格品。

---