With JavaScript approaching near-ubiquity as the scripting language of the web browser, it benefits you to have a basic understanding of its event-driven interaction model and how it differs from the request-response model typically found in languages like Ruby, Python, and Java. In this post, I’ll explain some core concepts of the JavaScript concurrency model, including its event loop and message queue in hopes of improving your understanding of a language you’re probably already writing but perhaps don’t fully understand.
随着网页浏览器脚本语言的javascript的日益普遍(几乎无所不在),了解它的时间驱动模式(event-driven interaction model )和请求响应模式(request-response model)的区别也变得更加有益.这篇文章中,我将解释一下javascript的核心观念(core concepts),包括,事件轮询( event loop),消息队列(message queue)希望能使你更加明白这门语言,可能你在用它,但你不太明白.
Who is this post for? (这篇文章为谁准备)
This post is aimed at web developers who are working with (or planning to work with) JavaScript in either the client or the server. If you’re already well-versed in event loops then much of this article will be familiar to you. For those of you who aren’t, I hope to provide you with a basic understanding such that you can better reason about the code you’re reading and writing day-to-day.
In JavaScript, almost all I/O is non-blocking. This includes HTTP requests, database operations and disk reads and writes; the single thread of execution asks the runtime to perform an operation, providing a callback function and then moves on to do something else. When the operation has been completed, a message is enqueued along with the provided callback function. At some point in the future, the message is dequeued and the callback fired.
While this interaction model may be familiar for developers already accustomed to working with user interfaces – where events like “mousedown,” and “click” could be triggered at any time – it’s dissimilar to the synchronous, request-response model typically found in server-side applications.
A slightly different look, and very different behavior:
看起来稍有不同,然而本质却大不相同:
The request function is executed, passing an anonymous function as a callback to execute when a response is available sometime in the future.
“Done!” is immediately output to the console
Sometime in the future, the response comes back and our callback is executed, outputting its body to the console
1.请求执行时,将一个回调函数作为参数传过去,这个回调函数将被执行当响应返回时.
2."Done!" 被输出到控制台
3.响应返回时,那个回调函数被执行,body被输出到控制台
The Event Loop(事件轮循)
The decoupling of the caller from the response allows for the JavaScript runtime to do other things while waiting for your asynchronous operation to complete and their callbacks to fire. But where in memory do these callbacks live – and in what order are they executed? What causes them to be called?
JavaScript runtimes contain a message queue which stores a list of messages to be processed and their associated callback functions. These messages are queued in response to external events (such as a mouse being clicked or receiving the response to an HTTP request) given a callback function has been provided. If, for example a user were to click a button and no callback function was provided – no message would have been enqueued.
In a loop, the queue is polled for the next message (each poll referred to as a “tick”) and when a message is encountered, the callback for that message is executed.
事件轮循中,队列一直循环(每一次循环称为一个"tick"),当事件被触发时,回调函数被执行.
The calling of this callback function serves as the initial frame in the call stack, and due to JavaScript being single-threaded, further message polling and processing is halted pending the return of all calls on the stack. Subsequent (synchronous) function calls add new call frames to the stack (for example, function init calls function changeColor).
link.addEventListener("click", function changeColor() {
this.style.color = "burlywood";
});
}
init();
view raw js-event-loop-listening.js hosted with ❤ by GitHub
In this example, a message (and callback, changeColor) is enqueued when the user clicks on the ‘foo’ element and an the “onclick” event fires. When the message is dequeued, its callback function changeColor is called. When changeColor returns (or an error is thrown), the event loop continues. As long as function changeColor exists, specified as the onclick callback for the ‘foo’ element, subsequent clicks on the element will cause more messages (and associated callback changeColor) to become enqueued.
If a function called in your code is asynchronous (like setTimeout), the provided callback will ultimately be executed as part of a different queued message, on some future tick of the event loop. For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function f() {
console.log("foo");
setTimeout(g, 0);
console.log("baz");
h();
}
function g() {
console.log("bar");
}
function h() {
console.log("blix");
}
f();
view raw js-event-loop-queueing-additional.js hosted with ❤ by GitHub
Due to the non-blocking nature of setTimeout, its callback will fire at least 0 milliseconds in the future and is not processed as part of this message. In this example, setTimeout is invoked, passing a callback function g and a timeout of 0 milliseconds. When the specified time elapses (in this case, almost instantly) a separate message will be enqueued containing g as its callback function. The resulting console activity would look like: “foo”, “baz”, “blix” and then on the next tick of the event loop: “bar”. If in the same call frame two calls are made to setTimeout – passing the same value for a second argument – their callbacks will be queued in the order of invocation.
Web Workers
Using Web Workers enables you to offload an expensive operation to a separate thread of execution, freeing up the main thread to do other things. The worker includes a separate message queue, event loop, and memory space independent from the original thread that instantiated it. Communication between the worker and the main thread is done via message passing, which looks very much like the traditional, evented code-examples we’ve already seen.
First, our worker:
1
2
3
4
5
6
7
// our worker, which does some CPU-intensive operation
var reportResult = function(e) {
pi = SomeLib.computePiToSpecifiedDecimals(e.data);
postMessage(pi);
};
onmessage = reportResult;
view raw js-event-loop-worker.js hosted with ❤ by GitHub
Then, the main chunk of code that lives in a script-tag in our HTML:
在网上无意中看到淘宝提交的hotspot patch，共四个，有意思，记录一下。
7050685：jsdbproc64.sh has a typo in the package name
7058036：FieldsAllocationStyle=2 does not work in 32-bit VM
7060619：C1 should respect inline and
CREATE TABLE sessions (
id CHAR(32) NOT NULL,
data TEXT,
last_accessed TIMESTAMP NOT NULL,
PRIMARY KEY (id)
);
<?php
/**
* Created by PhpStorm.
* User: michaeldu
* Date
public Vector<CartProduct> delCart(Vector<CartProduct> cart, String id) {
for (int i = 0; i < cart.size(); i++) {
if (cart.get(i).getId().equals(id)) {
cart.remove(i);
问题是首页在火狐、谷歌、所有IE中正常显示，列表页的页面在火狐谷歌中正常，在IE6、7、8中都不中，觉得可能那个地方设置的让IE系列都不认识，仔细查看后发现，列表页中没写HTML模板部分没有添加DTD定义，就是<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3
com.jcraft.jsch.JSchException: Auth cancel
at com.jcraft.jsch.Session.connect(Session.java:460)
at com.jcraft.jsch.Session.connect(Session.java:154)
at cn.vivame.util.ftp.SftpServerAccess.connec
centos p安装
yum -y install tree
mac os安装
brew install tree
首先来看tree的用法
tree 中文解释：tree
功能说明：以树状图列出目录的内容。
语 法：tree [-aACdDfFgilnNpqstux][-I <范本样式>][-P <范本样式
一. 实体类简述
实体类其实就是俗称的POJO,这种类一般不实现特殊框架下的接口，在程序中仅作为数据容器用来持久化存储数据用的
POJO（Plain Old Java Objects）简单的Java对象
它的一般格式就是
public class A{
private String id;
public Str
