既然Javascript有這么多缺陷，那為什么人們不參考它的功能開發(fā)一門新語言而是一直對(duì)它修改呢？JavaScript語言只花了十天時(shí)間就完成了設(shè)計(jì)，自然的設(shè)計(jì)并不完美。甚至，一旦頁面打開，彈出的小廣

既然Javascript有這么多缺陷，那為什么人們不參考它的功能開發(fā)一門新語言而是一直對(duì)它修改呢？

JavaScript語言只花了十天時(shí)間就完成了設(shè)計(jì)，自然的設(shè)計(jì)并不完美。甚至，一旦頁面打開，彈出的小廣告，都是用JS完成的。隨著Google地圖等應(yīng)用程序的發(fā)布，AJAX技術(shù)徹底火了JS，很多應(yīng)用程序使用AJAX，最重要的技術(shù)就是JavaScript。

盡管JavaScript有缺陷，但它仍在不斷升級(jí)。經(jīng)過不斷的改進(jìn)，現(xiàn)在的JS應(yīng)該說是優(yōu)秀的。隨著大前端時(shí)代的到來，節(jié)點(diǎn).js， 虛擬用戶.js等等技術(shù)，也讓JS的地位不可動(dòng)搖。想要完全取代JS，不是一夜之間。微軟推出了typescript，谷歌推出了dart來取代JS，但現(xiàn)在看來還有很長(zhǎng)的路要走。

沒有語言是完美的，就像沒有人是完美的一樣。程序員只需要找到最合適的語言。在未來，也許有一天，一種新的語言將取代JavaScript。

菜雞求問，c 里的epoll和java里的線程池到底怎么理解，優(yōu)劣如何？

服務(wù)器并發(fā)模型可分為單線程和多線程模型。這里的線程通常是指“I/O線程”，即負(fù)責(zé)I/O操作和協(xié)調(diào)任務(wù)分配的“管理線程”。實(shí)際的請(qǐng)求和任務(wù)通常由所謂的“工作線程”處理。在多線程模型中，每個(gè)線程不僅是一個(gè)I/O線程，而且也是一個(gè)工作線程。所以我們這里討論的是單I/O線程和多工作線程的模型，這也是最常用的服務(wù)器并發(fā)模型。這個(gè)模型在我的項(xiàng)目的服務(wù)器代碼中隨處可見。它還有一個(gè)名字叫做“半同步/半異步”模型。同時(shí)，這種模式也是生產(chǎn)者/消費(fèi)者（特別是多消費(fèi)者）模式的一種表現(xiàn)。

此體系結(jié)構(gòu)主要基于I/O多路復(fù)用的思想（主要是epoll，select/poll已過時(shí)）。通過單向I/O復(fù)用，可以實(shí)現(xiàn)高效的并發(fā)，避免多線程I/O來回切換的各種開銷。它清晰易管理?；诰€程池的多工作線程可以充分發(fā)揮和利用多線程的優(yōu)點(diǎn)，利用線程池進(jìn)程池進(jìn)一步提高資源的可重用性，避免線程過多。

Epoll是Linux中高并發(fā)服務(wù)器的完美解決方案，因?yàn)樗谑录|發(fā)，所以它不僅比select快一個(gè)數(shù)量級(jí)。

單線程epoll最多可觸發(fā)15000次。但是，在添加服務(wù)之后，由于大多數(shù)服務(wù)都處理數(shù)據(jù)庫，因此會(huì)出現(xiàn)阻塞。此時(shí)，必須使用多線程來加速。