你为什么放弃golang?

你为什么放弃golang?,第1张

因为内存管理粗糙。经常看到fmtxxx导致内存占用太多,反射导致内存占用太多的抱怨。

go语言适合写服务器组件,那种和业务数据无关的服务器。比如数据库服务器、web服务器、日志搜索引擎等。如果用来写一个crm管理系统,非常累,因为缺乏好多高级特性和庞大的第三方库,而且语法比较单一,总体感觉就跟写命令行差不多。

Go语言是谷歌2009发布的编程语言,这个语言发明的目的,就是为了在运行速度接近C/C++语言的基础上(注意是接近),降低开发者的门槛,减少开发难度。

Go语言,在功能上没有超过C/C++,适用者为没有C/C++经验的开发者,开发出接近C效率的程序。对于已经熟练掌握C/C++的开发者来说,Go语言没有优势,还要重学语法,适应开发环境,明显是不符合效率的。

总结

其实语言这东西,都有其优势和劣势。而且有些东西并不是纯技术的。比如java的优势在于清晰的语意表达。写代码的上限不高,但是下限也不低,适合工业开发。

而go呢,不得不说go在微服务这块有先天优势。毕竟java中要实现go的很多功能,需要引入第三方库。很笨重。而go原生支持,这个微服务就很轻巧。但是go的语法太活,工业用是一个挺大的弊端。

为什么golang的开发效率高看
golang是一编译型的强类型语言,它在开发上的高效率主要来自于后发优势,不用考虑旧有恶心的历史,又有一个较高的工程视角。良好的避免了程序员因为逗 { 需不需要独占一行 地这种革命问题打架,也解决了一部分趁编译时间找产品妹妹搭讪的阶级敌人。
它有自己的包管理机制,工具链成熟,从开发、调试到发布都很简单方便;
有反向接口、defer、coroutine等大量的syntactic sugar;
编译速度快,因为是强类型语言又有gc,只要通过编译,非业务毛病就很少了;
它在语法级别上支持了goroutine,这是大家说到最多的内容,这里重点提一下。首先,coroutine并不稀罕,语言并不能超越硬件、 *** 作系统实现神乎其神的功能。golang可以做到事情,其他语言也可以做到,譬如c++,在boost库里面自己就有的coroutine实现(当然用起来跟其他boost库一样恶心)。golang做的事情,是把这一套东西的使用过程简化了,并且提供了一套channel的通信模式,使得程序员可以忽略诸如死锁等问题。
goroutine的目的是描述并发编程模型。并发与并行不同,它并不需要多核的硬件支持,它不是一种物理运行状态,而是一种程序逻辑流程。它的主要目的不是利用多核提高运行效率,而是提供一种更容易理解、不容易出错的语言来描述问题。
实际上golang默认就是运行在单OS进程上面的,通过指定环境变量GOMAXPROCS才能转身跑在多OS进程上面。有人提到了的pomelo,开源本来是一件很不错的事情,但是基于自己对callback hell的偏见,我一直持有这种态度:敢用nodejs写大规模游戏服务器的人,都是真正的勇士 : ) 。
2、Erlang与Golang的coroutine有啥区别,coroutine是啥看
coroutine本质上是语言开发者自己实现的、处于user space内的线程,无论是erlang、还是golang都是这样。需要解决没有时钟中断;碰着阻塞式i\o,整个进程都会被 *** 作系统主动挂起;需要自己拥有调度控制能力(放在并行环境下面还是挺麻烦的一件事)等等问题。那为啥要废老大的劲自己做一套线程放user space里面呢看
并发是服务器语言必须要解决的问题;
system space的进程还有线程调度都太慢了、占用的空间也太大了。
把线程放到user space的可以避免了陷入system call进行上下文切换以及高速缓冲更新,线程本身以及切换等 *** 作可以做得非常的轻量。这也就是golang这类语言反复提及的超高并发能力,分分钟给你开上几千个线程不费力。
不同的是,golang的并发调度在i/o等易发阻塞的时候才会发生,一般是内封在库函数内;erlang则更夸张,对每个coroutine维持一个计数器,常用语句都会导致这个计数器进行reduction,一旦到点,立即切换调度函数。
中断介入程度的不同,导致erlang看上去拥有了preemptive scheduling的能力,而golang则是cooperative shceduling的。golang一旦写出纯计算死循环,进程内所有会话必死无疑;要有大计算量少i\o的函数还得自己主动叫runtimeSched()来进行调度切换。
3、golang的运行效率怎么样看
我是相当反感所谓的ping\pong式benchmark,运行效率需要放到具体的工作环境下面考虑。
首先,它再快也是快不过c的,毕竟底下做了那么多工作,又有调度,又有gc什么的。那为什么在那些benchmark里面,golang、nodejs、erlang的响应效率看上去那么优秀呢,响应快,并发强看并发能力强的原因上面已经提到了,响应快是因为大量非阻塞式i\o *** 作出现的原因。这一点c也可以做到,并且能力更强,但是得多写不少优质代码。
然后,针对游戏服务器这种高实时性的运行环境,GC所造成的跳帧问题确实比较麻烦,前面的大神 @达达 有比较详细的论述和缓解方案,就不累述了 。随着golang的持续开发,相信应该会有非常大的改进。一是屏蔽内存 *** 作是现代语言的大势所趋,它肯定是需要被实现的;二是GC算法已经相当的成熟,效率勉勉强强过得去;三是可以通过incremental的 *** 作来均摊cpu消耗。
用这一点点效率损失换取一个更高的生产能力是不是值得呢看我觉得是值得的,硬件已经很便宜了,人生苦短,让自己的生活更轻松一点吧: )。
4、基于以上的论述,我认为采用go进行小范围的MMORPG开发是可行的。

Golang作为一门强类型、高效的编程语言,适合用于游戏开发。目前有不少游戏公司和团队都在使用Golang进行游戏的开发。由于其高效、轻量级、并发性能强等特点,使得Golang能够大大提升游戏的性能和稳定性,同时其简洁的语法和强制代码规范的设计,也使得Golang编写的游戏代码易于维护和扩展。近年来,随着Golang在游戏开发领域的日益普及,越来越多的游戏团队正在使用Golang开发各种类型的游戏,包括大型网络游戏、手机游戏、桌面游戏等,尤其是谷歌在推广和使用Golang进行游戏服务器开发,进一步促进了Golang在游戏领域的发展。

首先,看一下TCP握手简单描绘过程:

其握手过程原理,就不必说了,有很多详细文章进行叙述,本文只关注研究重点。
在第三次握手过程中,如果服务器收到ACK,就会与客户端建立连接,此时内核会把连接从半连接队列移除,然后创建新的连接,并将其添加到全连接队列,等待进程调用。
如果服务器繁忙,来不及调用连接导致全连接队列溢出,服务器就会放弃当前握手连接,发送RST给客户端,即connection reset by peer。

在linux平台上,客户端在进行高并发TCP连接处理时,最高并发数量都要受系统对用户单一进程同时打开文件数量的限制(这是因为系统每个TCP都是SOCKET句柄,每个soker句柄都是一个文件),当打开连接超过限制,就会出现too many open files。
使用下指令查看最大句柄数量:

增加句柄解决方案

简单减少slave同步延案架构做优化尽量让主库DDL快速执行主库写数据安全性较高比sync_binlog=1innodb_flush_log_at_trx_commit = 1 类设置slave则需要高数据安全完全讲sync_binlog设置0或者关闭binloginnodb_flushlog设置0提高sql执行效率另外使用比主库更硬件设备作slave
mysql-563已经支持线程主复制原理丁奇类似丁奇表做线程Oracle使用数据库(schema)单位做线程同库使用同复制线程
sync_binlog=1
This makes MySQL synchronize the binary log’s contents to disk each time it commits a transaction
默认情况并每写入都binlog与硬盘同步 *** 作系统或机器(仅仅MySQL服务器)崩溃能binlog语句丢 失要想防止种情况使用sync_binlog全局变量(1安全值慢)使binlog每Nbinlog写入与硬盘 同步即使sync_binlog设置1,现崩溃能表内容binlog内容间存致性使用InnoDB表MySQL服务器 处理COMMIT语句整事务写入binlog并事务提交InnoDB两 *** 作间现崩溃重启事务InnoDB滚仍 存binlog用--innodb-safe-binlog选项增加InnoDB表内容binlog间致性(注释:MySQL 51需要--innodb-safe-binlog;由于引入XA事务支持该选项作废)该选项提供更程度安全使每事务 binlog(sync_binlog =1)(默认情况真)InnoDB志与硬盘同步该选项效崩溃重启滚事务MySQL服务器binlog剪切滚 InnoDB事务确保binlog反馈InnoDB表确切数据等并使服务器保持与主服务器保持同步(接收 滚语句)
innodb_flush_log_at_trx_commit (管用)
抱怨Innodb比MyISAM慢 100倍概忘调整值默认值1意思每事务提交或事务外指令都需要志写入(flush)硬盘费特别使用电 池供电缓存(Battery backed up cache)设2于运用特别MyISAM表转意思写入硬盘写入系统缓存志仍每秒flush硬 盘所般丢失超1-2秒更新设0更快点安全面比较差即使MySQL挂能丢失事务数据值2整 *** 作系统 挂才能丢数据

1为什么golang的开发效率高?
golang是一编译型的强类型语言,它在开发上的高效率主要来自于后发优势,不用考虑旧有恶心的历史,又有一个较高的工程视角。良好的避免了程序员因为“ { 需不需要独占一行 ”这种革命问题打架,也解决了一部分趁编译时间找产品妹妹搭讪的阶级敌人。
它有自己的包管理机制,工具链成熟,从开发、调试到发布都很简单方便;
有反向接口、defer、coroutine等大量的syntactic sugar;
编译速度快,因为是强类型语言又有gc,只要通过编译,非业务毛病就很少了;
它在语法级别上支持了goroutine,这是大家说到最多的内容,这里重点提一下。首先,coroutine并不稀罕,语言并不能超越硬件、 *** 作系统实现神乎其神的功能。golang可以做到事情,其他语言也可以做到,譬如c++,在boost库里面自己就有的coroutine实现(当然用起来跟其他boost库一样恶心)。golang做的事情,是把这一套东西的使用过程简化了,并且提供了一套channel的通信模式,使得程序员可以忽略诸如死锁等问题。
goroutine的目的是描述并发编程模型。并发与并行不同,它并不需要多核的硬件支持,它不是一种物理运行状态,而是一种程序逻辑流程。它的主要目的不是利用多核提高运行效率,而是提供一种更容易理解、不容易出错的语言来描述问题。
实际上golang默认就是运行在单OS进程上面的,通过指定环境变量GOMAXPROCS才能转身跑在多OS进程上面。有人提到了网易的pomelo,开源本来是一件很不错的事情,但是基于自己对callback hell的偏见,我一直持有这种态度:敢用nodejs写大规模游戏服务器的人,都是真正的勇士 : ) 。
2、Erlang与Golang的coroutine有啥区别,coroutine是啥?
coroutine本质上是语言开发者自己实现的、处于user space内的线程,无论是erlang、还是golang都是这样。需要解决没有时钟中断;碰着阻塞式i\o,整个进程都会被 *** 作系统主动挂起;需要自己拥有调度控制能力(放在并行环境下面还是挺麻烦的一件事)等等问题。那为啥要废老大的劲自己做一套线程放user space里面呢?
并发是服务器语言必须要解决的问题;
system space的进程还有线程调度都太慢了、占用的空间也太大了。
把线程放到user space的可以避免了陷入system call进行上下文切换以及高速缓冲更新,线程本身以及切换等 *** 作可以做得非常的轻量。这也就是golang这类语言反复提及的超高并发能力,分分钟给你开上几千个线程不费力。
不同的是,golang的并发调度在i/o等易发阻塞的时候才会发生,一般是内封在库函数内;erlang则更夸张,对每个coroutine维持一个计数器,常用语句都会导致这个计数器进行reduction,一旦到点,立即切换调度函数。
中断介入程度的不同,导致erlang看上去拥有了preemptive scheduling的能力,而golang则是cooperative shceduling的。golang一旦写出纯计算死循环,进程内所有会话必死无疑;要有大计算量少i\o的函数还得自己主动叫runtimeSched()来进行调度切换。
3、golang的运行效率怎么样?
我是相当反感所谓的ping\pong式benchmark,运行效率需要放到具体的工作环境下面考虑。
首先,它再快也是快不过c的,毕竟底下做了那么多工作,又有调度,又有gc什么的。那为什么在那些benchmark里面,golang、nodejs、erlang的响应效率看上去那么优秀呢,响应快,并发强?并发能力强的原因上面已经提到了,响应快是因为大量非阻塞式i\o *** 作出现的原因。这一点c也可以做到,并且能力更强,但是得多写不少优质代码。
然后,针对游戏服务器这种高实时性的运行环境,GC所造成的跳帧问题确实比较麻烦,前面的大神 @达达 有比较详细的论述和缓解方案,就不累述了 。随着golang的持续开发,相信应该会有非常大的改进。一是屏蔽内存 *** 作是现代语言的大势所趋,它肯定是需要被实现的;二是GC算法已经相当的成熟,效率勉勉强强过得去;三是可以通过incremental的 *** 作来均摊cpu消耗。
用这一点点效率损失换取一个更高的生产能力是不是值得呢?我觉得是值得的,硬件已经很便宜了,人生苦短,让自己的生活更轻松一点吧: )。
4、基于以上的论述,我认为采用go进行小范围的MMORPG开发是可行的。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/13443269.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-08-07
下一篇 2023-08-07

发表评论

登录后才能评论

评论列表(0条)

保存