在Golang中进行开发时，互斥锁在不断尝试获取永远无法获取的锁时会遇到 饥饿 问题。在本文中，我们将探讨影响Go 1.8的饥饿问题，该问题已在Go 1.9中解决。
我们提供的服务有：网站建设、成都网站建设、微信公众号开发、网站优化、网站认证、呼玛ssl等。为上千家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的呼玛网站制作公司
为了说明互斥锁的饥饿状况，我将以 拉斯·考克斯 （ Russ Cox）提出的 关于他们讨论互斥锁改进的 问题 为例：
starvation.go
此示例基于两个goroutine：
两者都具有100微秒的周期，但是由于goroutine 1一直在请求锁定，因此可以预期它将更频繁地获得锁定。
这是一个用Go 1.8进行的示例，该示例具有10次迭代的循环的锁分配：
该互斥锁已被第二个goroutine捕获了十次，而第一个则超过了700万次。让我们分析一下这里发生了什么。
首先，goroutine 1将获得锁定并睡眠100微秒。当goroutine 2尝试获取锁时，它将被添加到锁的队列（FIFO顺序）中，并且goroutine将进入等待状态：
Figure 1 — lock acquisition
然后，当goroutine 1完成工作时，它将释放锁定。此版本将通知队列唤醒goroutine 2。Goroutine 2将被标记为可运行，并正在等待Go Scheduler在线程上运行：
Figure 2— goroutine 2 is awoke
但是，在goroutine 2等待运行时，goroutine 1将再次请求锁定：
Figure 3— goroutine 2 is waiting to run
当goroutine 2尝试获取锁时，它将看到它已经具有保持状态并进入等待模式，如图2所示：
Figure 4— goroutine 2 tries again to get the lock
goroutine 2对锁的获取将取决于它在线程上运行所花费的时间。
现在已经确定了问题，让我们回顾可能的解决方案。
处理互斥量的方法有很多，例如：
barging mode
Go 1.8就是这样设计的，它反映了我们之前看到的内容。
handoff mode
我们可以 在Linux内核 的 互斥体中 找到此逻辑：
在我们的情况下，互斥锁切换会完美平衡两个goroutine之间的锁分配，但是会降低性能，因为这将迫使第一个goroutine即使未持有也要等待锁。
spinning mode
Go 1.8也使用此策略。当试图获取已经持有的锁时，如果本地队列为空且处理器数量大于一，则goroutine将旋转几次-如果仅使用一个处理器旋转就会阻塞程序。旋转后，goroutine将停放。如果程序大量使用锁，它可以作为快速路径。
有关如何设计锁的更多信息（ 插入 ，越区切换，自旋锁），通常， Filip Pizlo撰写 了必读的文章“ WebKit中的锁定 ”。
在Go 1.9之前，Go结合了插入和旋转模式。在1.9版中，Go通过添加新的饥饿模式解决了先前解释的问题，该模式将导致在解锁模式期间进行切换。
所有等待锁定时间超过一毫秒的goroutine，也称为 有界等待 ，将被标记为饥饿。当标记为饥饿时，解锁方法现在将把锁直接移交给第一位服务员。这是工作流程：
starvation mode
由于进入的goroutine将不会获取任何为下一个服务员保留的锁，因此在饥饿模式下也将禁用旋转。
让我们使用Go 1.9和新的starvation模式运行前面的示例：
现在的结果更加公平。现在，我们想知道新的控制层是否会对互斥体不处于饥饿状态的其他情况产生影响。正如我们在该程序包的基准测试（Go 1.8与Go 1.9）中所看到的，在其他情况下，性能并没有下降（不同处理器数量下， 性能会略有变化 ）：
翻译自：
没在windows下用过node-webkit，如果是我，我会选择PyQt。如果不考虑跨平台，C#就不错。Golang这方面没有成熟的东西，如果是学习体验的角度，可以用Golang。
1.Web App：iOS/Android的内置浏览器是基于webkit内核的，所以在开发webApp时，多数使用html或html5、CSS3、JavaScript技术做UI布局，使其在网站页面上实现传统的C／S架构软件功能。
服务端技术用java、php、ASP。现在也有很多一键生成webApp的平台，如百度siteApp／移动开发平台APICloud，APICloud平台提供基于腾讯x5浏览器引擎生成webApp，因为移动端的超级流量入口微信／手机qq等用的也是腾讯x5内置浏览器，这样可以帮助webApp引流。
2.Hybrid App：混合开发中主流的是以web为主体型的开发，即以网页语言编写，穿插Native功能的hybrid App开发类型，网页语言主要有html5、CSS3、JavaScript。Web主体型的App用户体验好坏，取决于底层中间件的交互与跨平台的能力。
国内外有很多优秀的开发工具，如国外的AppmAkr、Appmobi，国内的APICloud，APICloud的底层引擎用Deep Engine，使用半翻译式原理，将运行中的web翻译成Native API，并且支持扩展API，开发时可调用用原生语言开发的功能模块，以此达到媲美原生App的用户体验，同时节省开发时间。
go 可以开发桌面应用，但并不是很舒适。
可以使用的GUI库有：
1、goqt，LiteIDE作者出品，Go和QT的绑定，还未发布
2、go.uik，纯Go实现的并发UI工具
3、walk，Windows Application Library Kit
4、gform，Windows GUI framework
目前的话walk用得比较多
不过go的GUI库用起来没有C#、C/C++的那么顺手。
这个问题不久之后应该会有所改善，毕竟用Go开发桌面的需求在不断增加。
目前我采用的是用go http 做后端，Webkit+HTML5 做界面，表现力很好，前端不需要学习新知识，一般的管理类应用都能搞定。
参考：
Goroutine并发调度模型深度解析手撸一个协程池
Golang 的 goroutine 是如何实现的？
Golang - 调度剖析【第二部分】
OS线程初始栈为2MB。Go语言中，每个goroutine采用动态扩容方式，初始2KB，按需增长，最大1G。此外GC会收缩栈空间。
BTW，增长扩容都是有代价的，需要copy数据到新的stack，所以初始2KB可能有些性能问题。
更多关于stack的内容，可以参见大佬的文章。 聊一聊goroutine stack
用户线程的调度以及生命周期管理都是用户层面，Go语言自己实现的，不借助OS系统调用，减少系统资源消耗。
Go语言采用两级线程模型，即用户线程与内核线程KSE（kernel scheduling entity）是M:N的。最终goroutine还是会交给OS线程执行，但是需要一个中介，提供上下文。这就是G-M-P模型
Go调度器有两个不同的运行队列：
go1.10\src\runtime\runtime2.go
Go调度器根据事件进行上下文切换。
调度的目的就是防止M堵塞，空闲，系统进程切换。
详见 Golang - 调度剖析【第二部分】
Linux可以通过epoll实现网络调用，统称网络轮询器N（Net Poller）。
文件IO操作
上面都是防止M堵塞，任务窃取是防止M空闲
每个M都有一个特殊的G，g0。用于执行调度，gc，栈管理等任务，所以g0的栈称为调度栈。g0的栈不会自动增长，不会被gc，来自os线程的栈。
go1.10\src\runtime\proc.go
G没办法自己运行，必须通过M运行
M通过通过调度，执行G
从M挂载P的runq中找到G，执行G