Storm中境遇的日志多次重写问题(一)

来自 <http://blog.sina.com.cn/s/blog_6ff05a2c0101ficp.html>

  transferred栏突显的数字代表的是实际上tuple发送到下一个task的计数. 

  图片 1

  该问题的详细描述:http://www.cnblogs.com/xiangshancuizhu/archive/2012/10/22/2734497.html

品尝解决文件反复重写:

  第4类:调用线程不安全函数的函数

package bolt;

import java.io.FileWriter;
import java.io.IOException;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;

import topology.topo;
import backtype.storm.Config;
import backtype.storm.Constants;
import backtype.storm.task.OutputCollector;
import backtype.storm.task.TopologyContext;
import backtype.storm.topology.OutputFieldsDeclarer;
import backtype.storm.topology.base.BaseRichBolt;
import backtype.storm.tuple.Fields;
import backtype.storm.tuple.Tuple;
import backtype.storm.tuple.Values;

/**
 * 
 * 实现日志编写
 * author ZPF
 * 
 */

public class transGPS extends BaseRichBolt{

    private static final long serialVersionUID = -5653803832498574866L;

    public static int numOfGPS = 0;//统计计算GPS的次数 numOfGPS

    private static FileWriter writer = null;

    private static DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

    private static String fileName = "/home/storm/countflow";//定义写文件路径


    private OutputCollector collector;  
     public void prepare(Map config, TopologyContext context, OutputCollector collector) {  
         this. collector = collector;  
      }
     /*
      * 返回统计次数
      */
    public static int countGPS(){
        return numOfGPS;
    }

    @Override
    public void execute(Tuple tuple) {
        addGridNo.numOfGrid = topo.numOfGrid;
        numOfGPS = topo.numOfGPS;
        try {
            if(isTickTuple(tuple)){
                writer = new FileWriter(fileName, true);
                String str = null;
                writer.write("{\"time_stamp\":\"" +df.format(new Date())+ "\",\"process_name\":\"" + "strom_flow" 
                                + "\",\"from_kafka:"+addGridNo.numOfGrid
                                +"\",\"to_redis:"+topo.numOfGPS+"}\n");
                //writer.write("Grid and GPS "+df.format(new Date())+",strom_flow,"+topo.numOfGrid+","+topo.numOfGPS+"\n");
                writer.flush();
            }
            else{
                numOfGPS++;
                topo.numOfGPS++;
                String line = tuple.getString(0);//json格式
                    synchronized (collector){
                        collector.emit(new Values(line.toString()));
                    }    
                    synchronized (collector){  
                        collector.ack(tuple);  
                    }
                    synchronized (collector){  
                        collector.fail(tuple);  
                    }
            }
        }
    catch (IOException e1) {
            e1.printStackTrace();
        }

    }
    @Override
    public void declareOutputFields(OutputFieldsDeclarer declarer) {
        declarer.declare(new Fields("GPS02"));
    }
    @Override
    public Map<String, Object> getComponentConfiguration() {
        Map<String, Object> conf = new HashMap<String, Object>();
        conf.put(Config.TOPOLOGY_TICK_TUPLE_FREQ_SECS, 5);//每5s持久化一次数据
        return conf;
    }
//    @Override
//    public void cleanup() {
//
//        // TODO Auto-generated method stub
//
//        try {
//            writer = new FileWriter(fileName, true);
//            String str = null;
//            writer.write("{\"time_stamp\":\"" +df.format(new Date())+ "\",\"process_name\":\"" + "strom_flow" 
//                            + "\",\"from_kafka\":"+topo.numOfGrid
//                            +"\",\"to_redis\":"+topo.numOfGPS+"}\n");
//            //writer.write("Grid and GPS "+df.format(new Date())+",strom_flow,"+topo.numOfGrid+","+topo.numOfGPS+"\n");
//            writer.flush();
//            addGridNo.numOfGrid = topo.numOfGrid;
//            numOfGPS = topo.numOfGPS;
//
//        } catch (IOException e) {
//
//            // TODO Auto-generated catch block
//
//            e.printStackTrace();
//
//        }
//
//    }
    public static boolean isTickTuple(Tuple tuple) {

        return tuple.getSourceComponent().equals(Constants.SYSTEM_COMPONENT_ID)
                && tuple.getSourceStreamId().equals(Constants.SYSTEM_TICK_STREAM_ID);
        }    
    }

  某些函数(如gethostbyname)将总括结果放在静态结构中,并赶回一个对准这个社团的指针。假设大家从出现线程中调用这个函数,那么将可能发生灾难,因为正值被一个线程使用的结果会被另一个线程悄悄地覆盖了。

咱俩接纳可重入(reentrant)来概括显式可重入函数和隐式可重入函数。不过,可重入性有时是调用者和被调用者共有的习性,并不只是被调用者单独的特性3002

分析已知结果:

    传统关系型数据库很难安排实时总计,只好安排定时任务总计分析窗口数据 

使得rand函数变为线程安全的唯一模式是重写它,使得它不再拔取其他静态数据,取而代之地依靠调用者在参数中传递状态音信。这样的症结是,程序员现在要被迫改变调用程序的代码。

  首先,解释文件重写出现的案由:

                    
          图片 2

假如在利用并发时想动态地调整并发数,那需要追加很多额外的拍卖逻辑。因为Storm默认的fieldsGrouping是依据并发数举办Hash总结取模。倘使并发数变动,那么每个数据流应该分配到哪个task中也就爆发了改动。在故障复苏时,如果并发数暴发了扭转,每个task的task
ID也会暴发变化,这会招致一个task从数据库中读取不到自然属于自己的这有些中间状态数据。这时急需利用一致性Hash策略来缓解该问题。

    数据存储之后的变现,也是你需要协调处理的,storm UI
只提供对topology的督察和总计。 

  假如一个bolt A内部推行了emit操作, 然而没有指定tuple的接受者,
那么transferred将为0.

  线程安全:一个函数被称之为线程安全的(thread-safe),当且仅当被四个冒出进程反复调用时,它会一向发生不利的结果。假如一个函数不是线程安全的,大家就说它是线程不安全的(thread-unsafe)。大家定义四类(有相交的)线程不安全函数。

  可重入函数:可重入函数是线程安全函数的一种,其特点在于它们被多少个线程调用时,不会引用任何共享数据。可重入函数平时要比不足重入的线程安全函数效率高一些,因为它们不需要同步操作。更进一步说,将第2类线程不安全函数转化为线程安全函数的绝无仅有办法就是重写它,使之可重入。

  第3类:再次回到指向静态变量指针的函数

末段在topo的main函数中需要bulid一个topology。然后设置该topology的特性,以及指定读取数据的路线,数据利用何种分发情势,topology的面世数目为多少等息息相关设置。

分析造成该结果的原由:

出现的题材:

  此外collector.emit(new Values(xxx))和collector.emit(tuple, new
Values(xxx)) 这二种不同的emit方法也会影响后边bolt的emitted和transferred,
尽管是前者, 则后续bolt的这六个值都是0, 因为前一个emit方法是非安全的,
不再行使acker来进展校验.

    Bolt类接收由Spout或者此外上游Bolt类发来的Tuple,对其举行拍卖。Bolt组件的兑现可以经过连续BasicRichBolt类或者IRichBolt接口等来成功 

其余一种总计的法子

  • 经过名称 + 读kafka数据条数 + 写入redis数据条数 + 写入hbase条数 +
    写入kafka条数。time_stamp + process_name + from_kafka + to_redis +
    to_hdfs + to_kafka

 

    完整的Topology处理流程图为: 

工作描述:

当数据量大到自然水平常就要选拔并发,当现身需要考虑容错与事务性时处理逻辑又会变得复杂起来。在Storm中,每个bolt可以启动五个task,每一个task会有一个唯一的task
ID。当需要持久化操作时,每个task必须把团结的中间状态连带自己的task
ID一起持久化下来,而在故障复苏时,每个task只从数据库中读取属于自己的情状数据,否则很容易造成内存溢出。再加上有点业务逻辑要求两个task的多寡必须在数据库中一起commit,这又增多了复杂。

3.基于task的ID举办实时统计,每趟统计每一个task处理的多少,然后将task的总结结果发送给外部的总计函数,可能解决重写题目!!!

   
cleanup方法 —
同ISpout的close方法,在关门前调用。同样不保险其必然执行。
 

  第2类:保持跨越多少个调用的情况函数

 
  图片 3

  有二种方法来拍卖这类线程不安全函数。一种是接纳重写函数,使得调用者传递存放结果的社团地址。这就免去了具有共享数据,可是它要求程序员还要改写调用者的代码。

  第1类:不珍视共享变量的函数

  来自
<http://www.open-open.com/lib/view/open1430095563146.html>

某一个亟需总结的bolt中的代码

 

  Storm集群中有二种节点,一种是控制节点(Nimbus节点),另一种是做事节点(Supervisor节点)。所有Topology任务的付出必须在Storm客户端节点上拓展(需要安排
storm.yaml文件),由Nimbus节点分配给其他Supervisor节点举行拍卖。
Nimbus节点首先将交给的Topology进行分片,分成一个个的Task,并将Task和Supervisor相关的信息提交到
zookeeper集群上,Supervisor会去zookeeper集群上认领自己的Task,通告自己的Worker进程举办Task的处理。 

 

接下去就是联合重复数据,以及降低延时的处理了。

图片 4

  无论是使用线程依然利用静态的法子都是急需再bolt中的prepare函数中举办调用。按照上述对storm的周转以及协会解析,可以博得在分布式系统上的运转并不只是一台机器上简单的日记总括而言。原因就在于storm采取分布式系统举办多少的拍卖操作。那么函数的调用次数以及线程的开启个数一定不会等于1。那一点需要相当注意!!!分布式系统并不是在一台机械上跑,而且分布式系统在此而言是相对独立的。而且大家团结一心没辙提前将任务经行分配,比如说这一台机器跑多少个,另一台机械跑哪些。所以出现文件的再一次写入是难以避免的,而且是正常的。

分布式系统的确糟糕考虑,问题繁多的。

地方的运作结果是在设置每5秒举行写入文件。但是日子戳这里发生了问题。表明重新写入过程中留存严重的延时。那么接下去的干活除了统一重写的数量之外还要降低延时。

{"time_stamp":"2016-10-18 16:01:03","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:03","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:03","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:03","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:04","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:08","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:08","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:08","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:08","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:09","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:13","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:13","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:13","process_name":"strom_flow","from_kafka:1399","to_redis:503","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:13","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1401","to_redis:500","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1398","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

{"time_stamp":"2016-10-18 16:01:14","process_name":"strom_flow","from_kafka:1397","to_redis:502","to_hbase:120","to_hdfs:119","to_kafka:911}

Storm与观念关系型数据库 

package bolt;



import java.io.FileWriter;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;

import backtype.storm.Config;
import backtype.storm.Constants;
import backtype.storm.task.OutputCollector;
import backtype.storm.task.TopologyContext;
import backtype.storm.topology.OutputFieldsDeclarer;
import backtype.storm.topology.base.BaseRichBolt;
import backtype.storm.tuple.Fields;
import backtype.storm.tuple.Tuple;
import backtype.storm.tuple.Values;
import topology.topo;

/**
 * @author ZPF
 *
 */

public class addGridNo extends BaseRichBolt {
    private static final long serialVersionUID = -6586283337287975719L;
    public static int numOfGrid = 0;
    private static FileWriter writer = null;

    private static DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

    private static String fileName = "/home/storm/testflowgrid";//定义写文件路径
    private OutputCollector collector;

    public static int countGrid(){
        return numOfGrid;
    }

    @Override
    public void prepare(Map config, TopologyContext context, OutputCollector collector) {       
        this. collector = collector;
      }
    @Override
    public void execute(Tuple tuple) {
        topo.numOfGrid++;
        numOfGrid++;
        String line = tuple.getString(0);    

        synchronized (collector){ 
            collector.emit(new Values(line.toString()));
        }    
        synchronized (collector){  
            collector.ack(tuple); 
        }
        synchronized (collector){ 
            collector.fail(tuple);
        }

    }
    @Override
    public void declareOutputFields(OutputFieldsDeclarer declarer) {
        declarer.declare(new Fields("GPSWithGridNo"));
    }
}

                       图片 5

  倘使一个bolt A使用all group的形式(每一个bolt都要收取到)向bolt
B发射tuple, 此时bolt B启动了5个task,
那么trasferred呈现的数目将是emitted的5倍. 

  接下去需要解决的题目:

来自
<http://www.cnblogs.com/xiangshancuizhu/archive/2012/10/22/2734497.html>

唯独此地面临着 问题:task
ID是生成着的,假若某次程序崩溃,重启之后发出错误。

 

除外前边错误认为的文件重写之外,存在的此外一个题目就是时刻戳的延迟问题。举一些实际运行拿到的结果:

Storm不处理总结结果的保留,这是运用代码需要担当的事体,如果数据不大,你可以简简单单地保留在内存里,也得以每趟都更新数据库,也足以采纳NoSQL存储。这部分工作完全交由用户。

 

2.或者将写文件的函数写为可重入函数可能会迎刃而解问题!!!

  日志的再三重写以及时光戳的延时问题。

找出为啥退步以及文件再次读写是否真正是个错误。

  通过地方的解析,以及对storm的结构分析。这里曾经得以规定在此之前的论断是不对的。对于起头怀疑文件重写是个谬误的假若已经被验证是有失常态的。那么除了,在代码书写过程中,还有几点需要留意。

  1. numOfGrid以及numOfGPS以及此外的变量近年来都是声称为静态私有变量,这里numOfGrid和numOfGPS无论申明在bolt中如故topo中
    都是能够正确得到答案。
  2. 近期利用的总计方法。为了落实5秒向文件写一次数据。现在大概可以分成三种办法。一种是在交付topo之后开启一个线程举行总括和写入读入的多少条数。另一种方法是行使静态的函数,函数在bolt被调用。
  3. 每一个bolt都足以爆发四个task,这是从网上摘过来的,因而在一个bolt的prepare中
    运行的代码其实不只是运行了一次,到底是每一个task都运作了这些prepare仍然在每一台机械上都运行了这个prepare程序?倘诺运行次数不止一次的话,那么
    向文件中写入的线程或者静态程序就不光开启或者调用了五回,那么就足以解释了怎么爆发了文本的屡屡读写操作!!!
  4. 当一台机械出现故障,日常的是storm3崩溃了。那么最后的总括结果自然出现问题。至于结果是否可以大概地相加,现在如故不亮堂。为啥不亮堂能无法大概的相加呢?其一是不精晓线程究竟开启了不怎么个或者静态的总结函数究竟调用了稍稍次!另外如若简单的将重新的数码忽略的话,并且三台机械可以正常运作,那么最终的结果通过此外自己打开的一个topic测试过,消费的多寡和压入的总额据的条数相等。不过一台机械崩溃结果就不对等topic中的总数量条数!!
  5. 老师上课提到了线程安全题材,那么依据网上的执教来看,将变量全部安装为大局静态变量这势必是有题目标。假若将代码修改为可重入函数的话应该就可以解决文件重写那个题目。那么这几个角度来看,前提是线程开启的不停一个,而是两个。但是,假使不将变量设置为全局变量的话,只是为局部变量又需要怎么修改来实时总结处理数量的条数呢。或者只是在topo中装置全局变量,每一趟将一些变量传给外部,不过这依旧有全局变量啊。
  6. 翻看手册调用数量!!!

  

  可重入函数

  1.是因为程序运行在三台不同的机械上,在举办多线程操作时,程序是否是安全的很要紧!

  总括从kafka
spout中读取的多少条数,以及写入redis的多少的条数,写入hdfs的多寡条数,写入kafaka的多寡条数。并且每过5秒将数据依照json文件的花样写入日志。其中保存为json数据的格式为:时间戳

隐式可重入函数:可重入函数中的一些参数是引用传递(使用了指针),也就是说,在调用线程小心地传递指向非共享数据的指针时,它才是可重入的。例如rand_r就是隐式可重入的。

  emitted栏突显的数字代表的是调用OutputCollector的emit方法的次数.

    Storm不Hadoop,Spark(Spark)等是流行的大数量方案 

 
 图片 6

  可是按照下面提议的各类方案,经过尝试都未果了!

  已知的问题以及并发的结果:

来自 <http://www.open-open.com/lib/view/open1430095563146.html>

  

来自 <http://www.open-open.com/lib/view/open1430095563146.html>

图片 7

    关系型数据库重视事务,并发控制,相对来说Storm相比简陋 

   
prepare方法 —
此措施和Spout中的open方法类似,在集群中一个worker中的task开端化时调用。
它提供了bolt执行的环境

    传统关系型数据库是先存后总结,而storm则是先算后存,甚至不存 

  

和同一是精打细算框架的MapReduce比较,MapReduce集群上运行的是Job,而Storm集群上运行的是Topology。可是Job在运作停止将来会自动为止,Topology却只得被手动的kill掉,否则会直接运转下去

    execute方法 —
这是Bolt中最重大的一个措施,对于Tuple的拍卖都得以停放此方法中开展。具体的发送是经过emit方法来形成的。execute接受一个
tuple举行拍卖,并用prepare方法传入的OutputCollector的ack方法(表示成功)或fail(表示失利)来报告处理结果。

   
declareOutput菲尔德(Field)s方法 —
用于表明当前Bolt发送的Tuple中蕴藏的字段(field),和Spout中仿佛 

   
与Storm关系密切的言语:核心代码用clojure书写,实用程序用python开发,使用java开发拓扑 

package count;


import java.io.FileWriter;
import java.io.IOException;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;

import bolt.addGridNo;
import bolt.transGPS;
/*
 * 写在main函数里面了,因此只是跑在nimbus上面
 * 这样做是不对的!!!
 */
public class countflow{

    private static String fileName = "/home/storm/countflow";//定义写文件路径
    static FileWriter writer = null;//文件读写流
    //private static Timer timer = new Timer();//计时器,每过5秒钟进行写数据
//    private static countflow uniqueInstance;
//    private countflow(){}
//    public static countflow getInstance(){
//        if(uniqueInstance == null){
//            uniqueInstance = new countflow();
//        }
//        return uniqueInstance;
//    }
    /*
    public void run() {
        try {

            writer = new FileWriter(fileName, true);

        } catch (IOException e) {
            e.printStackTrace();
        }
        executeFixedRate();
        /*Timer timer = new Timer();
        timer.schedule(new count(writer), 0, 5000);//每过5秒调用新建一个count类并且将writer传入。
    }
    */
    /**
     * 以固定周期频率执行任务
     * @throws IOException 
     */
    public static void executeFixedRate() throws IOException {
        writer = new FileWriter(fileName, true);
        ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);
        executor.scheduleAtFixedRate(
                new count(writer),
                0,
                5000,
                TimeUnit.MILLISECONDS);
    }
    static class count implements Runnable{

        private FileWriter writer = null;
        //设置日期格式
        private static DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

        count(FileWriter writer){//构造函数
            this.writer = writer;
        }
        public void run(){//运行代码   
            try {
                writer.write("Bolt"+addGridNo.indexId+" From Grid and GPS "+"<"+df.format(new Date())+">strom_flow,<"+addGridNo.countGrid()+">,<"+transGPS.countGPS()+">\n");
                writer.flush();
            } catch (IOException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }   
    }
}

显式可重入函数:假如拥有函数的参数都是传值传递的(没有指针),并且具有的数码援引都是当地的全自动栈变量(也就是说没有引用静态或全局变量),那么函数就是突显可重入的,也就是说不管怎么调用,我们都可断言它是可重入的。

付出实现的根本代码:

来自 <http://blog.sina.com.cn/s/blog_6ff05a2c0101ficp.html>

  假使线程不安全函数是难以修改或不足修改的(例如,它是从一个库中链接过来的),那么此外一种选取就是行使lock-and-copy(加锁-拷贝)技术。这些定义将线程不安全函数与排斥锁联系起来。在各种调用地点,对互斥锁加锁,调用函数不安全函数,动态地为结果非配存储器,拷贝函数重临的结果到那些存储器地方,然后对互斥锁解锁。一个掀起人的浮动是概念了一个线程安全的卷入(wrapper)函数,它实施lock-and-copy,然后调用这么些封转函数来代表所无线程不安全的函数。

  来自
<http://www.cnblogs.com/xiangshancuizhu/archive/2012/10/22/2734497.html>

网站地图xml地图