管程, monitor 管程, 监视器, Moniter Java程序设计语言中，每个对象都可以作为一个管程。需要互斥使用的方法必须明确标示关键字 synchronized . 代码块也可以标示关键字synchronized. 不使用明确的条件变量, Java的这种管程在入口队列之外，使用单独的条件等待队列. 所有等待的线程进入这个队列， 所有的notify与notify all操作也施加于这个队列。这种方法已经被其它程序设计语言使用，如C#. Java中的同步方法与其他经典管程有本质差别: Java没有内嵌的条件变量。反之，Java提供了两个过程wait和notify ，分别与sleep和wakeup等价， 不过，当它们在同步方法中使用时，它们不受竞争条件约束。理论上，方法wait可以被中断，它本身就是与中断有关的代码。Java需要显式表示异常处理。 在JAVA中是如何实现管程？ 在Java虚拟机中，每个对象和类在逻辑上与管程相关联。为了实现管程的互斥能力，一个锁(有时也称为一个互斥锁)关联每个对象和类。这就是所谓操作系统书籍上的信号量(semaphore)，互斥锁是一个二进制信号量。 如果一个线程拥有一些数据的锁，那么没有其他线程可以获取这个锁，直到拥有锁的线程释放它。当我们做多线程编程时，如果任何时候都需要编写一个信号量，这将是不方便。幸运的是，我们并不需要，因为JVM自动为我们实现了。 声明一个管程区域，这意味着数据不能被超过一个线程访问，java提供同步代码块和同步方法。一旦代码被嵌入synchronized关键字，它就是一个管程区域。该锁在后台通过JVM自动实现。 3.在JAVA的同步代码中，哪一部分是管程？ 我们知道每个对象/类都关联一个管程。我认为更好的说法应该是每个对象都有一个管程，因为每个对象可以有它自己的临界区，并能够监控线程顺序。 为了使不同的线程协作，JAVA为提供了wait()和notify()来挂起线程和唤醒另外一个等待的线程。此外，还有其他3个方法: wait(long timeout, int nanos) wait(long timeout) notified by other threads or notified by timeout. notify(all) 这些方法只能在同步代码块或同步方法中调用。因为所有的这些方法都需要线程持有对象的锁，所以只能通过同步来实现。 管程 (英语: Moniters，也称为监视器) 是一种程序结构，结构内的多个子程序 (对象或模块) 形成的多个工作线程互斥访问共享资源。 这些共享资源一般是硬件设备或一群变量。管程实现了在一个时间点，最多只有一个线程在执行管程的某个子程序。 与那些通过修改数据结构实现互斥访问的并发程序设计相比，管程实现很大程度上简化了程序设计。 管程提供了一种机制，线程可以临时放弃互斥访问，等待某些条件得到满足后，重新获得执行权恢复它的互斥访问。 一个管程包含: 多个彼此可以交互并共用资源的线程 多个与资源使用有关的变量 一个互斥锁 一个用来避免竞态条件的不变量 一个管程的程序在运行一个线程前会先取得互斥锁，直到完成线程或是线程等待某个条件被满足才会放弃互斥锁。 若每个执行中的线程在放弃互斥锁之前都能保证不变量成立，则所有线程皆不会导致竞态条件成立。 当一个线程执行管程中的一个子程序时，称为占用(occupy)该管程. 管程的实现确保了在一个时间点，最多只有一个线程占用了该管程。这是管程的互斥锁访问性质。 当线程要调用一个定义在管程中的子程序时，必须等到已经没有其它线程在执行管程中的某个子程序。 在管程的简单实现中，编译器为每个管程对象自动加入一把私有的互斥锁。该互斥锁初始状态为解锁， 在管程的每个公共子程序的入口给该互斥锁加锁，在管程的每个公共子程序的出口给该互斥锁解锁。 条件变量(Condition Variable) 管程提供了一种实现互斥的简便途径，但这还不够。我们还需要一种办法使得线程在无法继续运行时被阻塞。 在生产者-消费者问题中，很容易将针对缓冲区满和缓冲区空的测试放到管程过程中，但是生产者在发现缓冲区满的时候如何阻塞呢？ 解决的方法是引入条件变量 (condition variables) 以及相关的两个操作: wait和signal。 ...

消息队列/message queue/MQ, CORBA, DCOM, RMI, RPC http://blog.csdn.net/mr_smile2014/article/details/47452281 消息队列是在消息的传输过程中保存消息的容器，消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。 一、 产生背景: 现今，越来越多的企业面临着各种各样的数据集成和系统整合，CORBA、DCOM、RMI 等RPC中间件技术也应运而生，但由于采用RPC同步处理技术，在性能、健壮性、可扩展性上都存在着诸多缺点。而基于消息的异步处理模型采用非阻塞的调用特性，发送者将消息发送给消息服务器，消息服务器在合适的时候再将消息转发给接收者；发送和接收是异步的，发送者无需等待，二者的生命周期也可以不必相同，而且发送者可以将消息间接传给多个接收者，大大提高了程序的性能、可扩展性及健壮性，这使得异步处理模型在分布式应用上比起同步处理模型更具有吸引力。 分布式对象调用，如CORBA，RMI 和DCOM，提供了一种通讯机制，透明地在异构的分布式计算环境中传递对象请求，这些对象可以位于本地或远程机器。它通过在对象与对象之间提供一种统一的接口，使对象之间的调用和数据共享不再关心对象的位置、实现语言及所驻留的操作系统。这个接口就是面向对象的中间件。 二、传统面向对象中间件的局限性 同步通信: 客户发出调用后，必须等待服务对象完成处理并返回结果后才能继续执行。 客户和服务对象的生命周期紧密耦合: 客户进程和服务对象进程都必须正常运行，如果由于服务对象崩溃或网络故障导致客户的请求不可达，客户会接收到异常。 三、面向消息的中间件的优越性 消息中间件作为一个中间层软件, 它为分布式系统中创建、发送、接收消息提供了一套可靠通用的方法，实现了分布式系统中可靠的、高效的、实时的跨平台数据传输。消息中间件减少了开发跨平台和网络协议软件的复杂性，它屏蔽了不同操作系统和网络协议的具体细节，面对规模和复杂度都越来越高的分布式系统。它与传统的面向对象中间件相比具有如下优点: 采用异步通信模式: 发送消息者可以在发送消息后进行其它的工作，不用等待接收者的回应，而接收者也不必在接到消息后立即对发送者的请求进行处理。 客户和服务对象生命周期的松耦合关系: 客户进程和服务对象进程不要求都正常运行，如果由于服务对象崩溃或者网络故障导致客户的请求不可达，客户不会接收到异常，消息中间件能保证消息不会丢失。 四、消息中间件的技术标准 消息中间件主要有JMS和AMQP两种技术标准； JMS Java关于消息服务的标准是JMS，JMS即Java消息服务 (Java Message Service) 应用程序接口是一个Java平台中关于面向消息中间件 (MOM) 的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，类似于JDBC，需要不同的提供商进行各自的实现。实现JMS标准的软件可以作为Java下的消息中间件服务器。JMS 使您能够通过消息收发服务 (有时称为消息中介程序或路由器) 从一个 JMS 客户机向另一个 JMS客户机发送消息。消息是 JMS中的一种类型对象，由两部分组成: 报头和消息主体。报头由路由信息以及有关该消息的元数据组成。消息主体则携带着应用程序的数据或有效负载。根据有效负载的类型来划分，可以将消息分为几种类型，它们分别携带: 简单文本(TextMessage)、可序列化的对象 (ObjectMessage)、属性集合 (MapMessage)、字节流 (BytesMessage)、原始值流 (StreamMessage)，还有无有效负载的消息 (Message)。 AMQP AMQP，即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。Erlang中的实现有 RabbitMQ等。

sql join 多个条件 SELECT a.* FROM product a LEFT JOIN product_details b ON a.id=b.id AND b.weight!=44 AND b.exist=0 WHERE b.id IS NULL; join inner join(等值连接) 只返回两个表中联结字段相等的行 left join (左联接) 返回包括左表中的所有记录和右表中联结字段相等的记录 right join(右联接) 返回包括右表中的所有记录和左表中联结字段相等的记录 INNER JOIN 语法: INNER JOIN 连接两个数据表的用法: SELECT * FROM 表1 INNER JOIN 表2 ON 表1.字段号=表2.字段号 INNER JOIN 连接三个数据表的用法: SELECT * FROM (表1 INNER JOIN 表2 ON 表1.字段号=表2.字段号) INNER JOIN 表3 ON 表1.字段号=表3.字段号 **INNER JOIN 连接四个数据表的用法: ** SELECT * FROM ((表1 INNER JOIN 表2 ON 表1.字段号=表2.字段号) INNER JOIN 表3 ON 表1.字段号=表3.字段号) INNER JOIN 表4 ON Member.字段号=表4.字段号 ...

jconsole http://jiajun.iteye.com/blog/810150 一、JConsole是什么 从Java 5开始 引入了 JConsole。JConsole 是一个内置 Java 性能分析器，可以从命令行或在 GUI shell 中运行。您可以轻松地使用 JConsole (或者，它更高端的 “近亲” VisualVM ) 来监控 Java 应用程序性能和跟踪 Java 中的代码。 二、如何启动JConsole 如果是从命令行启动，使 JDK 在 PATH 上，运行 jconsole 即可。 如果从 GUI shell 启动，找到 JDK 安装路径，打开 bin 文件夹，双击 jconsole 。 当分析工具弹出时 (取决于正在运行的 Java 版本以及正在运行的 Java 程序数量) ，可能会出现一个对话框，要求输入一个进程的 URL 来连接，也可能列出许多不同的本地 Java 进程 (有时包含 JConsole 进程本身) 来连接。如图所示: 想分析那个程序就双击那个进程。 三、如何设置JAVA程序运行时可以被JConsolse连接分析 本地程序 (相对于开启JConsole的计算机) ，无需设置任何参数就可以被本地开启的JConsole连接 (Java SE 6开始无需设置，之前还是需要设置运行时参数 -Dcom.sun.management.jmxremote ) 无认证连接 (下面的设置表示: 连接的端口为8999、无需认证就可以被连接) Java代码 收藏代码 -Dcom.sun.management.jmxremote.port=8999 \ ...

生产线节拍 流程的"节拍"(Cycle time)是指连续完成相同的两个产品(或两次服务，或两批产品)之间的间隔时间。换句话说，即指完成一个产品所需的平均时间。节拍通常只是用于定义一个流程中某一具体工序或环节的单位产出时间。如果产品必须是成批制作的，则节拍指两批产品之间的间隔时间。在流程设计中，如果预先给定了一个流程每天(或其它单位时间段)必须的产出，首先需要考虑的是流程的节拍。 在机械加工生产线的设计中，节拍是设计的一个很重要的因素。生产节拍的平衡很重要。生产节拍的公式为 t=60Tβ/N 式中t为生产节拍，T为一年基本工时，一般规定，按一班制工时为2360h/年，按两班制工时为4650h/年；β为复杂系数，一般取为0.65-0.85；N为生产线加工工件的年生产纲领。 机械加工生产线的主要分类有: 单一产品固定节拍生产线、单一产品非固定节拍生产线、成组产品可调节生产线、柔性制造生产线。

KubeKey sudo apt install socat conntrack ebtables ipset ipvsadm git clone https://github.com/kubesphere/kubekey.git cd kubekey ./build.sh -p cd output ./kk create cluster https://kubesphere.io/zh/docs/installing-on-linux/introduction/intro/

dstat dstat 是一个可以取代vmstat，iostat，netstat和ifstat这些命令的多功能产品。dstat克服了这些命令的局限并增加了一些另外的功能，增加了监控项，也变得更灵活了。dstat可以很方便监控系统运行状况并用于基准测试和排除故障。 dstat可以让你实时地看到所有系统资源，例如，你能够通过统计IDE控制器当前状态来比较磁盘利用率，或者直接通过网络带宽数值来比较磁盘的吞吐率（在相同的时间间隔内）。 dstat将以列表的形式为你提供选项信息并清晰地告诉你是在何种幅度和单位显示输出。这样更好地避免了信息混乱和误报。更重要的是，它可以让你更容易编写插件来收集你想要的数据信息，以从未有过的方式进行扩展。 Dstat的默认输出是专门为人们实时查看而设计的，不过你也可以将详细信息通过CSV输出到一个文件，并导入到Gnumeric或者Excel生成表格中。 https://linux.cn/article-3215-1.html pacman -S dstat

‘Linux 双显示器/多屏/扩展屏幕/xrandr’ Can’t open display :0 用 root 用户执行 xrandr 会报错 Can’t open display :0, 尝试用其它普通用户 https://www.reddit.com/r/linux4noobs/comments/lu1plx/hi_i_get_this_authorization_required_but_no/ 4k 显示器调整 dpi xrandr -display :0.0 --listmonitors xrandr -display :0 --listmonitors xrandr -display :0 --dpi 144 # 或者这样配置环境变量 export DISPLAY=:0 xrandr --listmonitors xrdb -query xdpyinfo|grep dots xdpyinfo | grep -B 2 resolution xrandr -verbose xrandr -output DVI-0 -left-of VGA-0 -auto 不带参数执行xrandr能够列出当前的显示设备和每个设备支持的模式。 edit xorg.conf add line Virtual 2560 1024 wiloon@debian:~$ xrandr Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 16384 x 16384 DFP1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0 + 1920x1080 60.0 1600x1200 60.0 1680x1050 60.0* 1400x1050 60.0 1600x900 60.0 1360x1024 60.0 1280x1024 60.0 1440x900 60.0 1280x960 60.0 1280x800 60.0 1280x768 60.0 1280x720 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 DFP2 disconnected (normal left inverted right x axis y axis) DFP3 disconnected (normal left inverted right x axis y axis) DFP4 disconnected (normal left inverted right x axis y axis) DFP5 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 408mm x 255mm 1680x1050 60.0*+ 1600x1200 60.0 1400x1050 60.0 1600x900 60.0 1360x1024 60.0 1280x1024 75.0 60.0 1440x900 59.9 1280x960 60.0 1280x800 60.0 1152x864 60.0 75.0 1280x768 60.0 1280x720 60.0 1024x768 75.0 70.1 60.0 800x600 72.2 75.0 60.3 56.2 640x480 75.0 72.8 66.6 59.9 CRT1 disconnected (normal left inverted right x axis y axis) wiloon@debian:~$ xrandr -output DFP1 -auto -left-of DFP5 xrandr -output DFP1 -mode 1920x1200 -left-of CRT2 -mode 1680x1050 wiloon@debian:~$ cvt 1680 1050 # 1680x1050 59.95 Hz (CVT 1.76MA) hsync: 65.29 kHz; pclk: 146.25 MHz Modeline "1680x1050_60.00" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync wiloon@debian:~$ xrandr -newmode "1680x1050" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync wiloon@debian:~$ xrandr -addmode VGA1 "1680x1050" wiloon@debian:~$ xrandr -output VGA1 -mode 1680x1050 设置显示分辨率及 xrandr 介绍 X Windows 中有一个显示分辨率的概念，在默认情况下，这个显示分辨率为 max*max ，max等于你的所有连接上的显示器中最大分辨率中的最大值。例如我的笔记本液晶屏最大分辨率为 1024*768，外接显示器最大分辨率为 1280*1024，则默认的显示分辨率为 1280*1280。如果我设置左右双屏且使用最大分辨率，那么总显示分辨率就会达到2304*1024，达到超出系统默认的大小。在这种情况下强行设置双屏幕，就会导致 X 进入超低分辨率，结果不得不手工重设 xrog.conf 来恢复。 为了更好检测这个问题，我们需要用到xrandr 这个软件，xrandr系统已经自带，如果没有请安装x11-xserver-utils: sudo apt-get install x11-xserver-utils 。 不带参数执行xrandr能够列出当前的显示设备和每个设备支持的模式。Screen代表了总显示区域，VGA代表显示器，LVDS代表笔记本液晶屏。 ...

JUDE,Astah 随着UML的扩大，UML建模工具也越来越庞大。不过，许多功能并不是用户所寻求的。因此，Astah Professional (原名JUDE) 听取用户心声，根据用户需要打造，按照使用习惯设计，轻便简单，友好易用，用户可以轻松使用它来高速建模，极大的提高了效率。 Astah Professional 功能强大，支持 UML1.4中所有图和主要的图形，元模 (Meta Model) 及属性，全面满足您建模所需，还集成了思维导图，工程合并，协作开发等十余项特色功能，以及许多方便用户的贴心实用的功能。 Astah Professional 是100% 纯 Java 应用程序，可以跨平台在各种主流操作系统中使用。支持 OMG XMI标准格式，可以与其它建模工具交互模型。为方便用户书写 Office 文档，软件支持以 Microsoft EMF 增强图元拷贝粘贴至 Microsoft Office，也可以将模型信息导出到 Office Excel。软件提供了内容丰富的使用手册，全面查看 Astah Professional 所有的功能。

基于REST的Web服务基础 代表性状态传输 (Representational State Transfer，REST) 在Web领域已经得到了广泛的接受，是基于SOAP和Web服务描述语言 (Web Services Description Language，WSDL) 的Web服务的更为简单的替代方法。接口设计方面这一转变的关键证据是主流Web 2.0服务提供者 (包括Yahoo、Google和Facebook) 对REST的采用，这些提供者弃用或放弃了基于SOAP和WSDL的接口，而采用了更易于使用、面向资源的模型来公开其服务。在本文中，Alex Rodriguez将向您介绍REST的基本原理。 基础 REST定义了一组体系架构原则，您可以根据这些原则设计以系统资源为中心的Web服务，包括使用不同语言编写的客户端如何通过HTTP处理和传输资源状态。如果考虑使用它的Web服务的数量，REST近年来已经成为最主要的Web服务设计模型。事实上，REST对Web的影响非常大，由于其使用相当方便，已经普遍地取代了基于SOAP和WSDL的接口设计。 REST这个概念于2000年由Roy Fielding在就读加州大学欧文分校期间在学术论文"Architectural Styles and the Design of Network-based Software Architectures"首次提出，他的论文中对使用Web服务作为分布式计算平台的一系列软件体系结构原则进行了分析，而其中提出的REST概念并没有获得现在这么多关注。多年以后的今天，REST的主要框架已经开始出现，但仍然在开发中，因为它已经被广泛接纳到各个平台中，例如通过JSR-311成为了Java? 6不可或缺的部分。 本文认为，对于今天正在吸引如此多注意力的最纯粹形式的REST Web服务，其具体实现应该遵循四个基本设计原则: ·显式地使用HTTP方法。 ·无状态。 ·公开目录结构式的URI。 ·传输XML、JavaScript Object Notation(JSON)，或同时传输这两者。 下面几个部分将详述这四个原则，并提供技术原理解释，说明为什么这些原则对REST Web服务设计人员非常重要。 显式地使用HTTP方法 基于REST的Web服务的主要特征之一是以遵循RFC 2616定义的协议的方式显式使用HTTP方法。例如，HTTP GET被定义为数据产生方法，旨在由客户端应用程序用于检索资源以从Web服务器获取数据，或者执行某个查询并预期Web服务器将查找某一组匹配资源然后使用该资源进行响应。 REST要求开发人员显式地使用HTTP方法，并且使用方式与协议定义一致。这个基本REST设计原则建立了创建、读取、更新和删除 (create, read, update, and delete，CRUD) 操作与HTTP方法之间的一对一映射。根据此映射: ·若要在服务器上创建资源，应该使用POST方法。 ·若要检索某个资源，应该使用GET方法。 ·若要更改资源状态或对其进行更新，应该使用PUT方法。 ·若要删除某个资源，应该使用DELETE方法。 许多Web API中所固有的一个令人遗憾的设计缺陷在于将HTTP方法用于非预期用途。例如，HTTP GET请求中的请求URI通常标识一个特定的资源。或者，请求URI中的查询字符串包括一组参数，这些参数定义服务器用于查找一组匹配资源的搜索条件。至少，HTTP/1.1 RFC是这样描述GET方法的。但是在许多情况下，不优雅的Web API使用HTTP GET来触发服务器上的事务性操作——例如，向数据库添加记录。在这些情况下，GET请求URI属于不正确使用，或者至少不是以基于REST的方式使用。如果Web API使用GET调用远程过程，则应该类似如下: GET /adduser?name=Robert HTTP/1.1 这不是非常优雅的设计，因为上面的Web方法支持通过HTTP GET进行状态更改操作。换句话说，该HTTP GET请求具有副作用。如果处理成功，则该请求的结果是向基础数据存储区添加一个新用户——在此例中为Robert。这里的问题主要在语义上。Web服务器旨在通过检索与请求URI中的路径 (或查询条件) 匹配的资源，并在响应中返回这些资源或其表示形式，从而响应HTTP GET请求，而不是向数据库添加记录。从该协议方法的预期用途的角度看，然后再从与HTTP/1.1兼容的Web服务器的角度看，以这种方式使用GET是不一致的。 除了语义之外，GET的其他问题在于，为了触发数据库中的记录的删除、修改或添加，或者以某种方式更改服务器端状态，它请求Web缓存工具 (爬网程序) 和搜索引擎简单地通过对某个链接进行爬网处理，从而意外地做出服务器端更改。克服此常见问题的简单方法是将请求URI上的参数名称和值转移到XML标记中。这样产生的标记是要创建的实体的XML表示形式，可以在HTTP POST的正文中进行发送，此HTTP POST的请求URI是该实体的预期父实体 (请参见清单1和2) : ...

Web 服务编程,REST 与 SOAP的比较 REST 简介 在开始我们的正式讨论之前,让我们简单看一下 REST 的定义。 REST (Representational State Transfer) 是 Roy Fielding 提出的一个描述互联系统架构风格的名词。为什么称为 REST？Web 本质上由各种各样的资源组成,资源由 URI 唯一标识。浏览器 (或者任何其它类似于浏览器的应用程序) 将展示出该资源的一种表现方式,或者一种表现状态。如果用户在该页面中定向到指向其它资源的链接,则将访问该资源,并表现出它的状态。这意味着客户端应用程序随着每个资源表现状态的不同而发生状态转移,也即所谓 REST。 关于 REST 本身,本文就不再这里过多地讨论,读者可以参考 developerWorks 上其它介绍 REST 的文章。本文的重点在于通过 REST 与 SOAP Web 服务的对比,帮助读者更深刻理解 REST 架构风格的特点,优势。 应用场景介绍 (在线用户管理) 本文将借助于一个应用场景,通过基于 REST 和 SOAP Web 服务的不同实现,来对两者进行对比。该应用场景的业务逻辑会尽量保持简单且易于理解,以有助于把我们的重心放在 REST 和 SOAP Web 服务技术特质对比上。 需求描述 这是一个在线的用户管理模块,负责用户信息的创建,修改,删除,查询。用户的信息主要包括: 用户名 (唯一标志在系统中的用户) 头衔 公司 EMAIL 描述 需求用例图如下: 图 1. 需求用例图 如图 1 所示,客户端 1 (Client1) 与客户端 2 (Client2) 对于信息的存取具有不同的权限,客户端 1 可以执行所有的操作,而客户端 2 只被允许执行用户查询 (Query User) 与用户列表查询 (Query User List) 。关于这一点,我们在对 REST Web 服务与 SOAP Web 服务安全控制对比时会具体谈到。下面我们将分别向您介绍如何使用 REST 和 SOAP 架构实现 Web 服务。 ...

REST是什么？ 概述 REST是英文Representational State Transfer的缩写，中文翻译: 表述性状态转移。 他是由Roy Thomas Fielding博士在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。 REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。 基于Web的架构，实际上就是各种规范的集合，这些规范共同组成了Web架构。比如Http协议，比如客户端服务器模式，这些都是规范。每当我们在原有规范的基础上增加新的规范， 就会形成新的架构。而REST正是这样一种架构，他结合了一系列的规范，而形成了一种新的基于Web的架构风格。 传统的Web应用大都是B/S架构，它包括了如下一些规范: 客户－服务器 这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了可能。 无状态性 无状态性是在客户－服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性 (无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史) ，可靠性 (无状态性减少了服务器从局部错误中恢复的任务量) ，可伸缩性 (无状态性使得服务器端可以很容易的释放资源，因为服务器端不必在多个request中保存状态) 。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上下文中，因此增加了在一系列request中发送重复数据的开销,严重的降低了效率。 3.缓存 为了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存 response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了信息，也就同时增加了客户端与服务器数据不一致的可能，从而降低了可靠性。 B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况， 我们引入了REST。 REST在原有的架构上增加了三个新规范: 统一接口，分层系统和按需代码。 1.统一接口 REST 架构风格的核心特征就是强调组件之间有一个统一的接口，这表现在REST世界里，网络上所有的事物都被抽象为资源，而REST就是通过通用的链接器接口对资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性。并且REST针对Web的常见情况做了优化，使得REST接口被设计为可以高效的转移大粒度的超媒体数据，这也就导致了REST接口对其它的架构并不是最优的。 2.分层系统 分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，这也就提高了系统的可伸缩性。 3.按需代码 REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码，来扩展客户端功能。但这在改善系统可扩展性的同时，也降低了可见性。所以它只是REST的一个可选的约束。 REST的设计准则 REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则: 网络上的所有事物都被抽象为资源 (resource) ； 每个资源对应一个唯一的资源标识符 (resource identifier) ； 3.通过通用的连接器接口 (generic connector interface) 对资源进行操作； 对资源的各种操作不会改变资源标识符； 所有的操作都是无状态的 (stateless) 。 REST中的资源所指的不是数据，而是数据和表现形式的组合，比如"最新访问的10位会员"和"最活跃的10为会员"在数据上可能有重叠或者完全相同，而由于他们的表现形式不同，所以被归为不同的资源，这也就是为什么REST的全名是Representational State Transfer的原因。资源标识符就是URI(Uniform Resource Identifier)，不管是图片，Word还是视频文件，甚至只是一种虚拟的服务，也不管你是xml格式,txt文件格式还是其它文件格式，全部通过 URI对资源进行唯一的标识。 REST是基于Http协议的，任何对资源的操作行为都是通过Http协议来实现。以往的Web开发大多数用的都是Http协议中的GET和 POST方法，对其他方法很少使用，这实际上是因为对Http协议认识片面的理解造成的。Http不仅仅是一个简单的运载数据的协议，而是一个具有丰富内涵的网络软件的协议。他不仅仅能对互联网资源进行唯一定位，而且还能告诉我们如何对该资源进行操作。Http把对一个资源的操作限制在4个方法以内: GET, POST,PUT和DELETE，这正是对资源CRUD操作的实现。由于资源和URI是一一对应的，执行这些操作的时候URI是没有变化的，这和以往的 Web开发有很大的区别。正由于这一点，极大的简化了Web开发，也使得URI可以被设计成更为直观的反映资源的结构，这种URI的设计被称作 RESTful的URI。这位开发人员引入了一种新的思维方式: 通过URL来设计系统结构。当然了，这种设计方式对一些特定情况也是不适用的，也就是说不是所有的URI都可以RESTful的。 ...

REST Web Service带给我们什么 Web Service的协议最近几年一直在发生转变。Web Servcie的最大优势是能在一个操作系统不同的各个系统之间架起沟通的桥梁，早期的 Web Service一般都是以SOAP协议传输。仔细学习和研究过SOAP协议的同学知道，SOAP协议是一个很完备的自解释协议，对Service、Interface、Method和Parameter的描述都非常详细，甚至还制定了一个WSDL的XSD来，在VS中，只要导入Web Service的WSDL，VS就可以自动生成存根代理代码，你只需调用它便可以调用这些SOAP的Web Service了。 SOAP 的Web Service看起来是很完美的解决方案，但是往往看起来完美的东西，用起来并不完美。 SOAP就是如此，随着Web Service 应用在企业级软件的运用，SOAP的缺陷迅速开始暴露出来。 首先，SOAP协议是在是太复杂，很少有人能完全看懂根据SOAP协议生成的数据 (其实这本来设计，就是给机器看的，哪能照顾你大爷，呵呵哦！) 。我本人是很厌烦看SOAP的数据，一看头就大，特别是SOAP头和尾。 其次，太复杂还不是SOAP协议最大的缺陷。大不了我用下解释SOAP的工具，现在VS也提供此类工具用来查看SOAP类型的数据。但是恰恰是这个缺陷造就了SOAP另一个很致命的缺陷。由于SOAP为了是每个调用的参数和返回值都可以独立解释，为此，需要在每次调用中加入大量的XML复杂信息，来解释这些数据。例如为了解释一个XML的节点是STRING，于是<datatype=“string”>被按在了一个XML节点上，其实这是没有必要的。因为，往往程序员在消费这个service的时候，已经知道了返回的数据类型，比如你在调用GetAge的时候，返回的XML肯定是int型。所以，一般一个SOAP的调用，一个来回少则数K，多则数M的，甚至数G的数据，而在这些数据中，真正有效的数据很少，根据统计，有效数据仅占全部数据的5%，甚至更少。对于海量数据的企业应用来说，大量的用户对海量数据的存储，如果用SOAP来进行数据传输，那简直就是灾难！！！ 另外，调式SOAP的WEB SERVICE也是很费时费力的，SOAP数据的难阅读性，直接增加了调式的难度。 所以，在REST之前，很多的企业应用还是用DCOM，甚至是自定义XML来进行数据传输。 那有没有很好协议的Web Service呢！？。。。现在。。。有了，REST的Web Service就是。 REST的Web Service彻底摒弃了SOAP协议。它的数据格式简单，一般都直接采用对象XML序列化的数据作为返回结果。这样就极大的降低了数据传输量，提高了效率。而且这种XML数据可以直接用IE打开，很容易阅读理解。 随着WCF和VS 2008的发布，MS首次加入了对架构REST Web Service的支持，虽然还很不完全，但是有总比没有好！现在，你只需: 1，添加Data Contract 2，添加Interface并附给URL 3，设置CLASS 4，附加到IIS或者CONSOLE程序 你就可以创建一个REST Web Service。然后通过IE，在地址栏输入Interface的URL，就想访问网页一样调用你的Web Service，返回的数据就通过IE直接显示，这够直观了吧！？ 现在，很多大型公司的Public Web Service也都已经REST化，比如GOOGLE所有的Web Service都是REST的，MS也已经采用REST来优化他的public WebService。很多"云计算"的提供商，如AMASON，他的"云服务" (呵呵，暂且如此叫吧) ，也是REST的。国内很多知名公司在看到REST的巨大优势后也纷纷开始采用REST的Web Service来提高他们的效率，如上海深睿科技的销售管理软件易卖通采用REST WebService，极大的提高了系统的速度和效率，使得传统的供销村管理软件架构在网络和"云"内成为可能。 总之，REST带给我们的是，一种更好、更简单、更有效率的Web Service，同时，可能将来成为"云计算"的基础通讯协议。

Hugo Hugo 是一款开源的使用 go 语言写的静态网站生成器,很适合数据量不大的个人博客使用 为何要使用静态网站生成器 (Static Site Generators) ？ 不同于 WordPress 这类博客平台 (以及其他众多流行的CMS内容管理系统) 在服务器端执行PHP等语言的动态框架、访问SQL数据库并动态产生Web页面的工作方式,静态网站生成器的原理十分简单: 将所有的页面、布局和帖子集合在一起,预先生成静态的站点。对于动态内容并非必要的站点——例如个人博客,静态网站生成器这样做有几个明显的优势 快速访问和弱服务器需求 静态HTML页面的载入速度理所当然地更快——因为它无需在服务器端执行任何代码。同时,这还大大地减轻了服务器的压力。 高安全性 基于与上述相同的理由,静态页面有着与生俱来的安全性。不像WordPress或者其他任何动态的框架,静态站点本身并不存在安全漏洞的问题。 版本控制 你无需通过WordPress来维护一整个复杂的数据库——静态站点的内容完全仅由文件系统中独立的目录和文件构成,这意味着你不但可以使用Shell、grep、sed、awk这些传统的Unix工具对它们执行操作和维护,更可以使用 Git 这样的分布式版本控制系统来管理它们,并且享受版本控制所带来的一切好处,如同维护任何软件项目的源代码库一样。你甚至可以重新生成以前任意时间点的整个网站！ 简单部署 一旦静态网站生成以后,任何Web服务器都能够轻易地部署静态站点,而无须在服务器端安装配置其他任何多余的东西。你所需要做的仅仅是通过git、rsync甚至ftp简单地上传文件到你的托管服务器。相比之下,WordPress博客的维护显得复杂得多,你可能需要在你的开发服务器和托管服务器上安装、配置一整套LAMP+WordPress平台,并经常性地升级版本和维护。这是个繁重的技术活。 文本编辑器和自由格式书写 也许你不这么认为,但是作为一个hacker而言,在浏览器中一个300x300的文本区里码字写博客并非一件很酷的事情——如果你使用Hugo这样的静态网站生成器,你就可以用你喜欢的任何文本编辑器 (vi、emacs……) ,用你习惯的标记语言以书写文本文件的方式来直接写博客文章 (就好像你平常写代码一样) ,避免了使用那些简陋和功能有限的Web界面。 compile # 安装 hugo pacman -S hugo # cd 到hugo工程目录 cd /path/to/markdown/doc/home # 在本地启动一个服务，测试一下，hugo会检测文档变化自动编译 hugo server # 开个浏览器看一下页面 google-chrome-stable http://localhost:1313/ hugo, plantuml https://mogeko.me/posts/zh-cn/083/

java JVM 内存问题 调查,调优 https://my.oschina.net/u/3345762/blog/1784199 https://my.oschina.net/u/3345762/blog/1644973 http://www.infoq.com/cn/articles/Troubleshooting-Java-Memory-Issues?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global http://www.importnew.com/14933.html http://lovestblog.cn/blog/2015/08/21/rssxmx/ # set jdk path export PATH=/usr/java/default/bin/:$PATH # list java process jcmd -l # show jcmd command jcmd PID help #heap dump jcmd PID GC.heap_dump /root/dump.hprof Eclipse Memory Analyzer Eclipse Memory Analyzer NMT, pmap Max memory = [-Xmx] + [-XX:MaxPermSize] + number_of_threads * [-Xss] init: represents the initial amount of memory (in bytes) that the Java virtual machine requests from the operating system for memory management during startup. The Java virtual machine may request additional memory from the operating system and may also release memory to the system over time. The value of init may be undefined. ...

Smalltalk Smalltalk被公认为历史上第二个面向对象的程序设计语言和第一个真正的集成开发环境 (IDE)。由Alan Kay，Dan Ingalls，Ted Kaehler，Adele Goldberg等于70年代初在Xerox PARC开发。Smalltalk对其它众多的程序设计语言的产生起到了极大的推动作用，主要有: Objective-C，Actor， Java 和Ruby等。90年代的许多软件开发思想得利于Smalltalk，例如Design Patterns， Extreme Programming(XP)和Refactoring等。 Smalltalk和许多程序设计语言不同，它不仅仅是一门语言。 一种面向对象的程序设计语言: 它是一种面向对象的语言，包含语言的语法和语义。一些编译器可以通过 Smalltalk 源程序产生可执行文件。这些编译器通常产生一种能在虚拟机上运行的二进制代码。Smalltalk语言本身非常精炼。 一种程序设计环境: 这里指的是一种提供许多 对象 的系统，而不是某种特殊的开发环境。和许多语言不同(包括C++)，Smalltalk附带有一个巨大的、相当标准的类库。这些 类 使得开发Smalltalk程序的效率非常高。在其它语言 (例如 Ada ， C 和 Pascal ) 中通常被作为语言的一部分的功能 (例如条件判断，循环等)，在Smalltalk由特定的类提供。 **一个应用开发环境(ADE):**由于Smalltalk的历史原因，它具有一个非常优秀的高度集成、开放的应用开发环境。由于开发环境中的浏览器、监视器以及调试器都由同样的源程序衍生出来的，不同的版本之间也具有相当好的兼容性。此外，这些工具的源程序都可以在ADE直接存取。

线框图 线框图(Wireframe)是软件或者网站设计过程中非常重要的一个环节。线框图是整合在结构层的全部三种要素的方法: 通过安排和选择界面元素来整合界面设计；通过识别和定义核心导航系统来整合导航设计；通过放置和排列信息组成部分的优先级来整合信息设计。通过把这三者放到一个文档中，线框图可以确定一个建立在基本概念结构上的架构，同时指出了视觉设计应该前进的方向。 其实对于更小或更简单的网站来说，一个线框图就足够作为所有即将建立的页面的模板。对于大多数项目来说，无论如何，都需要用多个线框图来传达复杂的预期结果。不过，你不需要为网站的每一个页面都准备一个线框图。正如结构设计流程允许我们把内容要素总结成各个种类一样，一个数量相对较少的标准页面类型将在绘制线框图的过程中慢慢浮现。 线框图在正式建立网站的视觉设计的流程中，是必要的第一步，但是几乎每一个参与这个开发过程的人都会在一些任务点中使用它。负责战略层、范围层和结构层的设计者可以借助线框图来保证最终产品能满足他们的期望。真正负责建设这个网站的人，则使用线框图来回答关于网站应该如何运作的问题。 随着用户体验领域的不断成熟和发展，线框图的责任有时还成为企业内部某种口水战的主题。一些网站研发团队很鲜明地把这部分工作分成两个部分，由两个独立的角色 (有时候是整个部门) “信息架构师"和"设计师"来承担。

悲观锁和乐观锁 为什么需要锁 (并发控制) ？ 在多用户环境中,在同一时间可能会有多个用户更新相同的记录,这会产生冲突。这就是著名的并发性问题。 典型的冲突有: 丢失更新: 一个事务的更新覆盖了其它事务的更新结果,就是所谓的更新丢失。例如: 用户A把值从 6 改为 2, 用户B把值从 2 改为 6, 则用户 A 丢失了他的更新。 脏读: 当一个事务读取其它完成一半事务的记录时, 就会发生脏读取。例如: 用户 A, B 看到的值都是 6, 用户 B 把值改为 2, 用户 A 读到的值仍为 6。 为了解决这些并发带来的问题。 我们需要引入并发控制机制。 并发控制机制 最常用的处理多用户并发访问的方法是加锁。当一个用户锁住数据库中的某个对象时,其他用户就不能再访问该对象。加锁对并发访问的影响体现在锁的粒度上。比如,放在一个表上的锁限制对整个表的并发访问；放在数据页上的锁限制了对整个数据页的访问；放在行上的锁只限制对该行的并发访问。可见行锁粒度最小,并发访问最好,页锁粒度最大,表锁介于2者之间。 悲观锁 悲观锁在操作数据时比较悲观,认为别人会同时修改数据。因此操作数据时直接把数据锁住,直到操作完成后才会释放锁；上锁期间其他人不能修改数据。 假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作。悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长,这样可能会长时间的限制其他用户的访问,也就是说悲观锁的并发访问性不好。 乐观锁 乐观锁在操作数据时非常乐观,认为别人不会同时修改数据。因此乐观锁不会上锁,只是在执行更新的时候判断一下在此期间别人是否修改了数据: 如果别人修改了数据则放弃操作,否则执行操作。 假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性。乐观锁不能解决脏读的问题。乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的,因此乐观锁直到你准备提交所作的更改时才将对象锁住,当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短,乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象,那么当他完成了自己的更改进行提交时,数据库就会发现该对象已经变化了,这样,第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中,会增加并发用户读取对象的次数。 从数据库厂商的角度看,使用乐观的页锁是比较好的,尤其在影响很多行的批量操作中可以放比较少的锁,从而降低对资源的需求提高数据库的性能。再考虑聚集索引。在数据库中记录是按照聚集索引的物理顺序存放的。如果使用页锁,当两个用户同时访问更改位于同一数据页上的相邻两行时,其中一个用户必须等待另一个用户释放锁,这会明显地降低系统的性能。interbase和大多数关系数据库一样,采用的是乐观锁,而且读锁是共享的,写锁是排他的。可以在一个读锁上再放置读锁,但不能再放置写锁；你不能在写锁上再放置任何锁。锁是目前解决多用户并发访问的有效手段。 乐观锁应用 使用自增长的整数表示数据版本号。更新时检查版本号是否一致,比如数据库中数据版本为6,更新提交时version=6+1,使用该version值(=7)与数据库version+1(=7)作比较,如果相等,则可以更新,如果不等则有可能其他程序已更新该记录,所以返回错误。 使用时间戳来实现. 注: 对于以上两种方式,Hibernate自带实现方式: 在使用乐观锁的字段前加 annotation: @Version, Hibernate在更新时自动校验该字段。 java中的乐观锁基本都是通过CAS操作实现的 悲观锁应用 结论 在实际生产环境里边,如果并发量不大且不允许脏读,可以使用悲观锁解决并发问题；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法. 参考文档 [1]Concurrent Control http://en.wikipedia.org/wiki/Concurrency_control [2] Oracle的悲观锁和乐观锁http://space.itpub.net/12158104/viewspace-374745 [3] timestamp应用——乐观锁和悲观锁【转】http://hi.baidu.com/piaokes/blog/item/9b0c6854e4909050564e00b3.html 事务隔离 https://www.cnblogs.com/kismetv/p/10787228.html http://www.cnblogs.com/Bob-FD/p/3352216.html

‘URL中#号(井号)的作用’ a href="#" 这表示一个空链接 这是一个空连接 href="#" #可以改成你要连接的地址 点击就链接到你的网址 这里可以随便你放什么字 这是html超链接格式,href是说超链接的目标,#就是自身 1. 井号在URL中指定的是页面中的一个位置 井号作为页面定位符出现在URL中,比如: http://www.httpwatch.com/features.htm#print ,此URL表示在页面features.htm中print的位置。浏览器读取这个URL后,会自动将print位置滚动至可视区域。 2.井号后面的数据不会发送到HTTP请求中 当时使用类似HttpWatch工具时,你是无法在Http请求中找到井号后面的参数的,原因是井号后面的参数是针对浏览器起作用的而不是服务器端。 3. 任务位于井号后面的字符都是位置标识符 不管第一个井号后面跟的是什么参数,只要是在井号后面的参数一律看成是位置标识符。 比如这样一个链接 (http://example.com/?color=#ffff&shape=circle) ,后面跟的参数是颜色和形状,但是服务器却并不能理解URL中的含义。服务器接收到的只是: http://example.com/?color= 4. 改变井号后面的参数不会触发页面的重新加载但是会留下一个历史记录 仅改变井号后面的内容,只会使浏览器滚动到相应的位置,并不会重现加载页面。 比如从_http://www.httpwatch.com/features.htm#filter_到_http://www.httpwatch.com/features.htm#print_,浏览器并不会去重新请求页面,但是此操作会在浏览器的历史记录中添加一次记录,即你可以通过返回按钮回答上次的位置。这个特性对Ajax来说特别的有用,可以通过设置不同井号值,来表示不同的访问状态,并返回不同的内容给用户。 (注: 在IE6和IE7下井号的改变不会增加历史记录。) 5、可以通过javascript使用window.location.hash来改变井号后面的值 window.location.hash这个属性可以对URL中的井号参数进行修改,基于这个原理,我们可以在不重载页面的前提下创造一天新的访问记录。如标记框架页面当前的页面: 除此之外,HTML 5新增的onhashchange事件,当#值发生变化时,就会触发这个事件。 6. Googlebot对井号的过滤机制 默认情况下Google在索引页面的时候会忽略井号后面的参数,同时也不会去执行页面中的javascript。然而谷歌为了支持对Ajax生成内容的索引,定义了如果在URL中使用"#!",则Google会自动将其后面的内容转成查询字符串_escaped_fragment_的值。 比如最新的twitter URL: http://twitter.com/#!/username,Google会自动请求_http://twitter.com/?escaped_fragment=/username_来获取Ajax内容。 另外可以用#结合?等元素来标记流量来源,比如区分竞价和自然流量等,这个就很给力了. http://blog.163.com/seo_luofeng/blog/static/17657502420120913641444/

javascript Location location.href 返回整个当前url,若对其赋值: location.href=“http://www.highya.com” 则跳转其url location.host 返回域名和端口号，如: www.highya.com:80 lcation.hostname 返回域名 location.port 返回端口 location.pathname 返回域名后第一个斜框后的字符串 location.hash 跳到本页的某个锚 location.search 取url?后的部分 location对象: location提供了关于当前打开窗口或者特定框架的url信息。一个多框架的窗口对象在location属性显示的是父窗口的URL，每个框架也有一个与之相伴的location对象。 hash属性: hash标注是一个url很好的习惯用法，它指定浏览器到一个位于文档中的anchor位置，相当于一个书签儿。 host属性: 描述渔歌url的主机名和端口，只有端口号是url的一个明确部分时，值中才包括端口号。 hostname属性: 一个典型的url的主机名是网络上服务器的名字，该网络存储有你的浏览器上可以查看的文档。对大多数Web站点来说，服务器名不仅包括域名，也包括www前缀，如果端口号是在url中特有的话，主机名并不包括，而是包括在host属性中。 href属性: 该属性提供一个指定窗口对象的整个url的字符串。 pathname属性: url的路径名部分由与服务器root (根) 卷相关的目录结构组成。根不是目录的一部分，如果url的路径是通向根目录中的一个文件，那么location.pathname属性就是 (/) 。 port属性: 端口号很少用到。当指向一个没有赋给域名的的站点的url中，可以用location.port属性获取该值，如果从一个url获取值并想用那个组建创建一个url，一定要包括服务器IP地址和段口号，IP地址和段口号之间用 (:) 分界。 protocol属性: 包括协议名，且后面紧跟着 (:) 分节目。 assign方法: assign(“url”)通过这个方法可以实现把一个新的url赋给location对象。当然你也可以采用直接赋值的方法来实现，或者location.href来导航到一个新的网页。采用assign的方法会使代码易维护。 reload方法: 这个方法可以把浏览器可能保存在内存中的元素 (在一段记录中) 的文档设置全部忽略掉，重新打开该文档，和浏览器上的刷新可不一样。它的效果好像是你选择了file菜单open file一样。当然如果你不想这样，不想这么做，有一个和这个方法比较类似的方法，就是history.go () 方法。 replace方法: 当用户从当前网页，跳转到别的网页，有时候是不是想让不能用后退按钮(Back)看到前一个网页，告诉你一个方法，就是采用location.replace(“url”)就可以实现这个功能。