BufferedImage是什么用法？

Image是一个抽象列，BufferedImage是Image的实现。

10年积累的成都网站建设、网站制作经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站制作后付款的网站建设流程，更有绥江免费网站建设让你可以放心的选择与我们合作。

Image和BufferedImage的主要作用就是将一副图片加载到内存中。

Java将一副图片加载到内存中的方法是：

Java代码  

String imgPath = "C://demo.jpg";  

BufferedImage image = ImageIO.read(new FileInputStream(imgPath));  

该方法可以获得图片的详细信息，例如：获得图片的宽度：image.getWidth(null);图片只有加

载内存中才能对图片进行进一步的处理。

java

Java是一种可以撰写跨平台应用程序的面向对象的程序设计语言。Java 技术具有卓越的通用性、高效性、平台移植性和安全性，广泛应用于PC、数据中心、游戏控制台、科学超级计算机、移动电话和互联网，同时拥有全球最大的开发者专业社群。

简介

它最初被命名为Oak，目标设定在家用电器等小型系统的编程语言，来解决诸如电视机、电话、闹钟、烤面包机等家用电器的控制和通讯问题。由于这些智能化家电的市场需求没有预期的高，Sun放弃了该项计划。就在Oak几近失败之时，随着互联网的发展，Sun看到了Oak在计算机网络上的广阔应用前景，于是改造了Oak，以“Java”的名称正式发布。

java标志Java的主要工作是通过编程语言来制作互联网页面、制作动态效果以及网站等技术，现在网上关于这方面的教程有很多，但很多都是过时的，因为互联网是在不断的变化的，互联网上的牛人，要想成为Java大神，走进这条Java大神之群，首先Java教程的开头是二三一，Java的最中间是三一四，Java的最后面再加上零二八，把前面的综合起来，Java大神期待你的加入。这里有很多互联网大牛教你学习，还有免费的课程。不是想学习的就不要加了。

如何用go语言每分钟处理100万个请求

在Malwarebytes 我们经历了显著的增长，自从我一年前加入了硅谷的公司，一个主要的职责成了设计架构和开发一些系统来支持一个快速增长的信息安全公司和所有需要的设施来支持一个每天百万用户使用的产品。我在反病毒和反恶意软件行业的不同公司工作了12年，从而我知道由于我们每天处理大量的数据，这些系统是多么复杂。

有趣的是，在过去的大约9年间，我参与的所有的web后端的开发通常是通过Ruby on Rails技术实现的。不要错怪我。我喜欢Ruby on Rails，并且我相信它是个令人惊讶的环境。但是一段时间后，你会开始以ruby的方式开始思考和设计系统，你会忘记，如果你可以利用多线程、并行、快速执行和小内存开销，软件架构本来应该是多么高效和简单。很多年期间，我是一个c/c++、Delphi和c#开发者，我刚开始意识到使用正确的工具可以把复杂的事情变得简单些。

作为首席架构师，我不会很关心在互联网上的语言和框架战争。我相信效率、生产力。代码可维护性主要依赖于你如何把解决方案设计得很简单。

问题

当工作在我们的匿名遥测和分析系统中，我们的目标是可以处理来自于百万级别的终端的大量的POST请求。web处理服务可以接收包含了很多payload的集合的JSON数据，这些数据需要写入Amazon S3中。接下来，map-reduce系统可以操作这些数据。

按照习惯，我们会调研服务层级架构，涉及的软件如下：

Sidekiq

Resque

DelayedJob

Elasticbeanstalk Worker Tier

RabbitMQ

and so on…

搭建了2个不同的集群，一个提供web前端，另外一个提供后端处理，这样我们可以横向扩展后端服务的数量。

但是，从刚开始，在 讨论阶段我们的团队就知道我们应该使用Go，因为我们看到这会潜在性地成为一个非常庞大（ large traffic）的系统。我已经使用了Go语言大约2年时间，我们开发了几个系统，但是很少会达到这样的负载（amount of load）。

我们开始创建一些结构，定义从POST调用得到的web请求负载，还有一个上传到S3 budket的函数。

type PayloadCollection struct {

WindowsVersion string `json:"version"`

Token string `json:"token"`

Payloads []Payload `json:"data"`

}

type Payload struct {

// [redacted]

}

func (p *Payload) UploadToS3() error {

// the storageFolder method ensures that there are no name collision in

// case we get same timestamp in the key name

storage_path := fmt.Sprintf("%v/%v", p.storageFolder, time.Now().UnixNano())

bucket := S3Bucket

b := new(bytes.Buffer)

encodeErr := json.NewEncoder(b).Encode(payload)

if encodeErr != nil {

return encodeErr

}

// Everything we post to the S3 bucket should be marked 'private'

var acl = s3.Private

var contentType = "application/octet-stream"

return bucket.PutReader(storage_path, b, int64(b.Len()), contentType, acl, s3.Options{})

}

本地Go routines方法

刚开始，我们采用了一个非常本地化的POST处理实现，仅仅尝试把发到简单go routine的job并行化：

func payloadHandler(w http.ResponseWriter, r *http.Request) {

if r.Method != "POST" {

w.WriteHeader(http.StatusMethodNotAllowed)

return

}

// Read the body into a string for json decoding

var content = PayloadCollection{}

err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)

if err != nil {

w.Header().Set("Content-Type", "application/json; charset=UTF-8")

w.WriteHeader(http.StatusBadRequest)

return

}

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

go payload.UploadToS3() // ----- DON'T DO THIS

}

w.WriteHeader(http.StatusOK)

}

对于中小负载，这会对大多数的人适用，但是大规模下，这个方案会很快被证明不是很好用。我们期望的请求数，不在我们刚开始计划的数量级，当我们把第一个版本部署到生产环境上。我们完全低估了流量。

上面的方案在很多地方很不好。没有办法控制我们产生的go routine的数量。由于我们收到了每分钟1百万的POST请求，这段代码很快就崩溃了。

再次尝试

我们需要找一个不同的方式。自开始我们就讨论过， 我们需要保持请求处理程序的生命周期很短，并且进程在后台产生。当然，这是你在Ruby on Rails的世界里必须要做的事情，否则你会阻塞在所有可用的工作 web处理器上，不管你是使用puma、unicore还是passenger（我们不要讨论JRuby这个话题）。然后我们需要利用常用的处理方案来做这些，比如Resque、 Sidekiq、 SQS等。这个列表会继续保留，因为有很多的方案可以实现这些。

所以，第二次迭代，我们创建了一个缓冲channel，我们可以把job排队，然后把它们上传到S3。因为我们可以控制我们队列中的item最大值，我们有大量的内存来排列job，我们认为只要把job在channel里面缓冲就可以了。

var Queue chan Payload

func init() {

Queue = make(chan Payload, MAX_QUEUE)

}

func payloadHandler(w http.ResponseWriter, r *http.Request) {

...

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

Queue - payload

}

...

}

接下来，我们再从队列中取job，然后处理它们。我们使用类似于下面的代码：

func StartProcessor() {

for {

select {

case job := -Queue:

job.payload.UploadToS3() // -- STILL NOT GOOD

}

}

}

说实话，我不知道我们在想什么。这肯定是一个满是Red-Bulls的夜晚。这个方法不会带来什么改善，我们用了一个 有缺陷的缓冲队列并发，仅仅是把问题推迟了。我们的同步处理器同时仅仅会上传一个数据到S3，因为来到的请求远远大于单核处理器上传到S3的能力，我们的带缓冲channel很快达到了它的极限，然后阻塞了请求处理逻辑的queue更多item的能力。

我们仅仅避免了问题，同时开始了我们的系统挂掉的倒计时。当部署了这个有缺陷的版本后，我们的延时保持在每分钟以常量增长。

最好的解决方案

我们讨论过在使用用Go channel时利用一种常用的模式，来创建一个二级channel系统，一个来queue job，另外一个来控制使用多少个worker来并发操作JobQueue。

想法是，以一个恒定速率并行上传到S3，既不会导致机器崩溃也不好产生S3的连接错误。这样我们选择了创建一个Job/Worker模式。对于那些熟悉Java、C#等语言的开发者，可以把这种模式想象成利用channel以golang的方式来实现了一个worker线程池，作为一种替代。

var (

MaxWorker = os.Getenv("MAX_WORKERS")

MaxQueue = os.Getenv("MAX_QUEUE")

)

// Job represents the job to be run

type Job struct {

Payload Payload

}

// A buffered channel that we can send work requests on.

var JobQueue chan Job

// Worker represents the worker that executes the job

type Worker struct {

WorkerPool chan chan Job

JobChannel chan Job

quit chan bool

}

func NewWorker(workerPool chan chan Job) Worker {

return Worker{

WorkerPool: workerPool,

JobChannel: make(chan Job),

quit: make(chan bool)}

}

// Start method starts the run loop for the worker, listening for a quit channel in

// case we need to stop it

func (w Worker) Start() {

go func() {

for {

// register the current worker into the worker queue.

w.WorkerPool - w.JobChannel

select {

case job := -w.JobChannel:

// we have received a work request.

if err := job.Payload.UploadToS3(); err != nil {

log.Errorf("Error uploading to S3: %s", err.Error())

}

case -w.quit:

// we have received a signal to stop

return

}

}

}()

}

// Stop signals the worker to stop listening for work requests.

func (w Worker) Stop() {

go func() {

w.quit - true

}()

}

我们已经修改了我们的web请求handler，用payload创建一个Job实例，然后发到JobQueue channel，以便于worker来获取。

func payloadHandler(w http.ResponseWriter, r *http.Request) {

if r.Method != "POST" {

w.WriteHeader(http.StatusMethodNotAllowed)

return

}

// Read the body into a string for json decoding

var content = PayloadCollection{}

err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)

if err != nil {

w.Header().Set("Content-Type", "application/json; charset=UTF-8")

w.WriteHeader(http.StatusBadRequest)

return

}

// Go through each payload and queue items individually to be posted to S3

for _, payload := range content.Payloads {

// let's create a job with the payload

work := Job{Payload: payload}

// Push the work onto the queue.

JobQueue - work

}

w.WriteHeader(http.StatusOK)

}

在web server初始化时，我们创建一个Dispatcher，然后调用Run()函数创建一个worker池子，然后开始监听JobQueue中的job。

dispatcher := NewDispatcher(MaxWorker)

dispatcher.Run()

下面是dispatcher的实现代码：

type Dispatcher struct {

// A pool of workers channels that are registered with the dispatcher

WorkerPool chan chan Job

}

func NewDispatcher(maxWorkers int) *Dispatcher {

pool := make(chan chan Job, maxWorkers)

return Dispatcher{WorkerPool: pool}

}

func (d *Dispatcher) Run() {

// starting n number of workers

for i := 0; i d.maxWorkers; i++ {

worker := NewWorker(d.pool)

worker.Start()

}

go d.dispatch()

}

func (d *Dispatcher) dispatch() {

for {

select {

case job := -JobQueue:

// a job request has been received

go func(job Job) {

// try to obtain a worker job channel that is available.

// this will block until a worker is idle

jobChannel := -d.WorkerPool

// dispatch the job to the worker job channel

jobChannel - job

}(job)

}

}

}

注意到，我们提供了初始化并加入到池子的worker的最大数量。因为这个工程我们利用了Amazon Elasticbeanstalk带有的docker化的Go环境，所以我们常常会遵守12-factor方法论来配置我们的生成环境中的系统，我们从环境变了读取这些值。这种方式，我们控制worker的数量和JobQueue的大小，所以我们可以很快的改变这些值，而不需要重新部署集群。

var (

MaxWorker = os.Getenv("MAX_WORKERS")

MaxQueue = os.Getenv("MAX_QUEUE")

)

直接结果

我们部署了之后，立马看到了延时降到微乎其微的数值，并未我们处理请求的能力提升很大。

Elastic Load Balancers完全启动后，我们看到ElasticBeanstalk 应用服务于每分钟1百万请求。通常情况下在上午时间有几个小时，流量峰值超过每分钟一百万次。

我们一旦部署了新的代码，服务器的数量从100台大幅 下降到大约20台。

我们合理配置了我们的集群和自动均衡配置之后，我们可以把服务器的数量降至4x EC2 c4.Large实例，并且Elastic Auto-Scaling设置为如果CPU达到5分钟的90%利用率，我们就会产生新的实例。

总结

在我的书中，简单总是获胜。我们可以使用多队列、后台worker、复杂的部署设计一个复杂的系统，但是我们决定利用Elasticbeanstalk 的auto-scaling的能力和Go语言开箱即用的特性简化并发。

我们仅仅用了4台机器，这并不是什么新鲜事了。可能它们还不如我的MacBook能力强大，但是却处理了每分钟1百万的写入到S3的请求。

处理问题有正确的工具。当你的 Ruby on Rails 系统需要更强大的web handler时，可以考虑下ruby生态系统之外的技术，或许可以得到更简单但更强大的替代方案。

bufferedreaderreadline换行符不完全卡死

bufferedreaderreadline换行符不完全卡死

问题1 Java调用python返回值一直为null

问题2 BufferedReader的readline函数无任何输出结果，进程长时间卡住

最近在做项目时，需要用到Java调用python文件并读取运行结果。一般Java调用简单的Python文件(不包含第三方库的)是没有任何问题的，但是我需要用到tensorflow、keras、numpy等第三方库，所以遇到了很多麻烦，经过各种百度查找，最终解决了问题，在这里做一个总结归纳。

问题1 Java调用python返回值一直为null

这个问题是我没有创建虚拟环境造成的，因为自己电脑上用的一直是Anaconda安装时自带的python，没有创建自己的虚拟环境，因此在Java中调用python文件时，就会找不到各种第三方库的问题。

问题2 BufferedReader的readline函数无任何输出结果，进程长时间卡住

这个问题我也找了很多方法才解决，产生这个问题的主要原因是：

命令在运行的过程中会向标准输出或者标准错误输出写出数据，但JVM又没有去读，导致缓冲区满，进而导致进程阻塞。因为我的python文件调用的tensorflow，他会输出一堆警告信息，这些警告信息属于错误流(ErrorStream)，如果我们没有及时处理，就会导致缓冲区占满，从而导致进程阻塞。

Process.getInputStream()和Process.getErrorStream()分别返回Process的标准输出流和错误流，两个流如果处理不当，其缓冲区不能被及时清除而被塞满，则进程被阻塞，即使调用Process.destory()也未必能销毁被阻塞的子进程。

这个问题的解决的方法比较简单，既然问题是缓冲区满之后没有及时清理，那么只要在Java代码里去读一下数据，保证缓冲区不会满即可.

golang中bufio包

一、介绍go标准库中的bufio

最近用golang写了一个处理文件的脚本，由于其中涉及到了文件读写，开始使用golang中的 io 包，后来发现golang 中提供了一个bufio的包，使用这个包可以大幅提高文件读写的效率，于是在网上搜索同样的文件读写为什么bufio 要比io 的读写更快速呢？根据网上的资料和阅读源码，以下来详细解释下bufio的高效如何实现的。

bufio 包介绍

bufio包实现了有缓冲的I/O。它包装一个io.Reader或io.Writer接口对象，创建另一个也实现了该接口，且同时还提供了缓冲和一些文本I/O的帮助函数的对象。

以上为官方包的介绍，在其中我们能了解到的信息如下：

bufio 是通过缓冲来提高效率

简单的说就是，把文件读取进缓冲（内存）之后再读取的时候就可以避免文件系统的io 从而提高速度。同理，在进行写操作时，先把文件写入缓冲（内存），然后由缓冲写入文件系统。看完以上解释有人可能会表示困惑了，直接把 内容-文件 和 内容-缓冲-文件相比， 缓冲区好像没有起到作用嘛。其实缓冲区的设计是为了存储多次的写入，最后一口气把缓冲区内容写入文件。下面会详细解释

bufio 封装了io.Reader或io.Writer接口对象，并创建另一个也实现了该接口的对象

io.Reader或io.Writer 接口实现read() 和 write() 方法，对于实现这个接口的对象都是可以使用这两个方法的

注明：介绍内容来自博主 LiangWenT

，原文链接： ，在查找资料时，发现这篇博客的内容很好理解

bufio包实现了缓存IO。它包装了io.Reader和io.Write对象，创建了另外的Reader和Writer对象，它们也实现了io.Reader和io.Write接口，具有缓存。注意：缓存是放在主存中，既然是保存在主存里，断电会丢失数据，那么要及时保存数据。

二、常用内容

1、Reader类型

NewReaderSize

作用：NewReaderSize将rd封装成一个带缓存的bufio.Reader对象。缓存大小由size指定（如果小于16则会被设为16）。如果rd的基类型就是有足够缓存的bufio.Reader类型，则直接将rd转换为基类型返回。

NewReader

funcReader相当于NewReaderSize(rd, 4096)

Peek

Peek返回缓存的一个切片，该切片引用缓存中前n个字节的数据，该操作不会将数据读出，只是引用，引用的数据在下一次读取操作之前有效的。如果切片长度小于n，则返回一个错误信息说明原因。如果n大于缓存的总大小，则返回ErrBufferFull。

Read

Read从b中数据到p中，返回读出的字节数和遇到的错误。如果缓存不为空，则只能读出缓冲中的数据，不会从底层io.Reader中提取数据，如果缓存为空，则：

1、len(p) = 缓存大小，则跳过缓存，直接从底层io.Reader中读出到p中

2、len(p) 缓存大小，则先将数据从底层io.Reader中读取到缓存中，再从缓存读取到p中。

Buffered

Buffered返回缓存中未读取的数据的长度。

Discard

Discard跳过后续的n个字节的数据，返回跳过的字节数。

Writer类型和方法

write结构

NewWriteSize

NewWriterSize将wr封装成一个带缓存的bufio.Writer对象，缓存大小由size指定（如果小于4096则会被设置未4096）。

NewWrite

NewWriter相等于NewWriterSize(wr, 4096)

WriteString

WriteString功能同Write，只不过写入的是字符串

WriteRune

WriteRune向b写入r的UTF-8编码，返回r的编码长度。

Flush

Available

Available 返回缓存中未使用的空间的长度

Buffered

Buffered返回缓存中未提交的数据长度

Reset

Reset将b的底层Write重新指定为w，同时丢弃缓存中的所有数据，复位所有标记和错误信息。相当于创建了一个新的bufio.Writer。

GO中还提供了Scanner类型，处理一些比较简单的场景。如处理按行读取输入序列或空格分隔的词等。

内容来自：

参考链接：

1）

2）

名称栏目：go语言buffered Go语言核心编程 pdf
网页路径：http://scyanting.com/article/higcji.html