【Java多线程】写入同一文件,自定义线程池与线程回收利用

原创
2014/01/23 18:28
阅读数 4K

csv的数据格式。


一个文件好几百兆,1个文件大概200万行左右的数据,现在我要解决的问题是,将 csv的数据读出来,组合数据,生成sql文件。

  

以前单线程跑,跑了一下午才完成,大概跑了几个小时。多线程跑,大概2-3分钟左右,200万条数据,包括过滤。

 

这个场景在平常开发中也是经常要用到的。发出来,希望大家能够指导学习~

优化版地址:http://my.oschina.net/u/1017195/blog/195508


package test.com.linapex.room;

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileOutputStream;
import java.io.FileReader;
import java.io.OutputStreamWriter;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.locks.ReentrantReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock;
import com.linapex.common.util.FileUtils;
import com.linapex.common.util.ZhengzeValidate;

public class TBuilderRoomSqlFileTool
{
	final static int DATACACHENUM = 10000;

	static int currThreadCount = 0;
	static int maxThreadCount = 10;

	static File roomFilterLogFile = new File("roomFilter.log");
	static File sqlFile = new File("roomSql.sql");
	static File csvFile = new File("D:\\baiduyundownload\\asd\\2000W\\1-200W.csv");

	final static String sqlStrTemplate = "INSERT INTO `t_room_record`(id,name, card, gender, birthday, address, zip, mobile, email, version) VALUES (null,':0', ':1', ':2', ':3', ':4', ':5', ':6', ':7',':8');";

	public static BufferedWriter initSQLWrite() throws Exception
	{
		if (sqlFile.exists())
		{
			sqlFile.delete();

			if (!sqlFile.createNewFile())
			{
				System.err.println("创建文件失败:" + sqlFile.getAbsolutePath());
			}
		}

		return new BufferedWriter(new OutputStreamWriter(new FileOutputStream(sqlFile, true), "UTF-8"));
	}

	public static void loadCSV(CallBack2 callBack) throws Exception
	{
		BufferedReader reader = null;
		try
		{
			reader = new BufferedReader(new FileReader(csvFile));
			String str = null;

			int num = 0;
			while ((str = reader.readLine()) != null)
			{
				num++;
				callBack.call(num, str);
			}
		} finally
		{
			reader.close();
		}
	}

	public static void main(String[] args) throws Exception
	{
		final ExecutorService threadPool = Executors.newFixedThreadPool(maxThreadCount);

		final List<Future<Object>> threadResultList = new ArrayList<Future<Object>>();

		final WriteSqlHandle writeSqlFile = new WriteSqlHandle(initSQLWrite(), DATACACHENUM);

		long begin = System.currentTimeMillis();

		loadCSV(new CallBack2()
		{

			@Override
			public void call(int num, String str)
			{
				String[] strs = str.split(",");

				if (strs.length < 8)
				{
					writeLog("此条数据不录入::0", Arrays.toString(strs));
					return;
				}

				String name = strs[0].trim();
				if (!ZhengzeValidate.isChina(name))
				{
					writeLog("此条数据不录入::0", Arrays.toString(strs));
					return;
				}

				try
				{
					String card = strs[4];
					String gender = strs[5];
					String birthday = strs[6];
					String address = strs[7];
					String zip = strs[8];
					String mobile = strs[20];
					String email = strs[22];
					String version = strs[31];

					//生成sql语句
					final String tempSql = tm(sqlStrTemplate, name, card, gender, birthday, address, zip, mobile, email, version);

					//添加数据,如果超出了缓存数据,则 开始写入文件系统
					if (writeSqlFile.add(tempSql))
					{
						currThreadCount++;

						//如果提交的线程过多,则取回之后再提交.
						if (currThreadCount >= maxThreadCount)
						{
							System.out.println(String.format("当前线程数:%s 允许最大线程数:%s 等待线程完成回调.", currThreadCount, maxThreadCount));
							for (Future<Object> fs : threadResultList)
							{
								try
								{
									fs.get();
									currThreadCount--;
									System.out.println("已回调线程数:" + (maxThreadCount - currThreadCount));
								} catch (Exception e)
								{
									e.printStackTrace();
								}
							}

							threadResultList.clear(); //清空
							currThreadCount = threadResultList.size();
							System.out.println(String.format("重新开始提交线程   当前线程数:%s 允许最大线程数:%s 等待线程完成回调.", currThreadCount, maxThreadCount));
						}

						Future future = threadPool.submit(new Runnable()
						{
							@Override
							public void run()
							{
								try
								{
									writeSqlFile.save();
								} catch (Exception e)
								{
									e.printStackTrace();
								}
							}
						});

						threadResultList.add(future);
						//						System.out.println(String.format("开启了%s条线程(保存了%s条数据)", curr_thread_count, num));
					}

				} catch (Exception e)
				{
					writeLog("录入错误的数据::0", Arrays.toString(strs));
					writeLog("错误的原因::0", e.getMessage());
				}
			}
		});

		writeSqlFile.flush();

		threadPool.shutdown();

		long end = System.currentTimeMillis() - begin;

		System.out.println(String.format("任务完成时间:%s", end));

	}

	public static void writeLog(String str, Object... values)
	{
		FileUtils.doWriteFile(roomFilterLogFile.getAbsolutePath(), tm(str, values) + "\r\n", null, false);
	}

	public static String tm(String strSource, Object... values)
	{
		if (strSource == null)
		{
			return null;
		}

		StringBuilder builder = new StringBuilder(strSource);

		final String prefix = ":";
		for (int index = 0; index < values.length; index++)
		{
			String value = values[index].toString();
			if (value == null)
			{
				continue;
			}

			String key = new StringBuilder(prefix).append(index).toString();

			int i = -1;
			if ((i = builder.indexOf(key, i)) > -1)
			{
				int len = key.length();
				builder.replace(i, i + len, value);
			}
		}

		return builder.toString();
	}

}

class WriteSqlHandle
{
	ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();

	WriteLock writeLock = readWriteLock.writeLock();

	List<String> cacheList;

	BufferedWriter bw;

	int dataCacheNum;

	public WriteSqlHandle(BufferedWriter bw)
	{
		this.bw = bw;
		cacheList = new ArrayList<String>();
	}

	public WriteSqlHandle(BufferedWriter bw, int dataCacheNum)
	{
		this.bw = bw;
		this.dataCacheNum = dataCacheNum;
		cacheList = new ArrayList<String>(dataCacheNum);
	}

	public boolean add(String sqlStr)
	{
		writeLock.lock();

		cacheList.add(sqlStr);

		writeLock.unlock();

		return cacheList.size() >= dataCacheNum;
	}

	public void save() throws Exception
	{
		writeLock.lock();

		long begin = System.currentTimeMillis();

		System.out.println(String.format("%s,准备消费   需要保存数据的集合长度:%s", Thread.currentThread().getName(), cacheList.size()));

		for (String str : cacheList)
		{
			bw.write(str + "\r\n");
		}

		long end = System.currentTimeMillis() - begin;

		System.out.println(String.format("%s,消费完成,耗费时间:%s ms,消费数据长度:%s", Thread.currentThread().getName(), end, cacheList.size()));

		cacheList.clear(); //清空数据.

		writeLock.unlock();
	}

	public void flush() throws Exception
	{
		System.out.println(String.format("flush线程:%s, 需要保存数据的集合长度:%s", Thread.currentThread().getName(), cacheList.size()));

		for (String str : cacheList)
		{
			bw.write(str + "\r\n");
		}

		System.out.println(String.format("flush线程:%s, 消费完成,消费数据长度:%s", Thread.currentThread().getName(), cacheList.size()));

		cacheList.clear(); //清空数据

		closeWrite();
	}

	private void closeWrite() throws Exception
	{
		bw.flush();
		bw.close();
	}

}

interface CallBack2
{
	void call(int num, String str);
}


如果需要测试代码的朋友,请修改

1、FileUtils.doWriteFile 改成 System.out 输出

2、将数据过滤去掉即可。


输出的日志,经过优化,代码效率从2-3分钟提高了1分钟多点:

pool-1-thread-8,准备消费   需要保存数据的集合长度:0
pool-1-thread-8,消费完成,耗费时间:0 ms,消费数据长度:0
已回调线程数:8
已回调线程数:9
pool-1-thread-9,准备消费   需要保存数据的集合长度:0
pool-1-thread-9,消费完成,耗费时间:0 ms,消费数据长度:0
已回调线程数:10
重新开始提交线程   当前线程数:0 允许最大线程数:10 等待线程完成回调.
pool-1-thread-10,准备消费   需要保存数据的集合长度:4
pool-1-thread-10,消费完成,耗费时间:0 ms,消费数据长度:4
flush线程:main, 需要保存数据的集合长度:9102
flush线程:main, 消费完成,消费数据长度:9102
任务完成时间:104797 ms



不允许转载~~~只能看,不能摸/偷笑






展开阅读全文
打赏
0
17 收藏
分享
加载中

引用来自“linapex”的评论

引用来自“哈库纳”的评论

引用来自“linapex”的评论

引用来自“哈库纳”的评论

昨天小试了一下,根据你的SQL模板生成1000W条SQL并写入文件共计 1.6G 的文件体积,大概耗时2~3分钟。
然后抛去写文件操作根据SQL模板用“sql.replaceAll(":\\d+", "aaa")”的查找替换方法拼接 SQL 大概用了 1分10秒,分析一下 replaceAll 这个方法用了正则表达式,是效率低下的主要原因。
以上测试结果是单线程下。

悠悠然然 提到的提升10倍不敢确定,不过5倍提升应该不是问题了把。
这个程序主要面临的问题还是 IO,多线程这块完全是个花瓶。此外 博主用到了 “锁”,锁也是一个很占 IO 的东西。

没有看懂,如何进行测试的。

多线程操作就是争抢那把锁,其实也只有一个线程在完成写操作.

提升10倍效率不敢想,5倍可能?能否贴贴代码?

程序瓶颈主要是IO问题,多线程这块用处可大了,每个线程处理自己的数据,最后归并啊,多线程资源分配啊,很多可以扩展的点。

刚才读取一个 1.85G的CSV格式的文件,耗时 199320 ms,3分钟左右。测试代码是经过优化过后的,在这里: http://my.oschina.net/u/1017195/blog/195508

5倍是个估量结果,现在的执行效率比上一个版本已经快出很多了。仍然3分钟的时间,处理数据的能力提升了至少2倍了把?
---------------
你这里代码还有很多可优化点,首先 ArrayList 初始大小好像只有10,当超过 10个元素之后它会自动扩大,这个操作会引发 ArrayList 内部把数组重新拷贝一次。建议直接把它的初始大小就设置成缓存的大小。
----------------------
或者干脆放弃 ArrayList 改为每个线程一个使用 ByteArrayOutputStream 作为输出缓存。缓存满了就排队写文件,用ByteArrayOutputStream 好处是你可以有机会把在 tm 方法中的 StringBuilder 去掉。

当然优化掉 StringBuilder 或许还有别的办法。

祝你好运

已经设置成了 数据缓存大小。

final WriteSqlHandle2 writeSqlFile = new WriteSqlHandle2(DATACACHENUM);
public WriteSqlHandle2(int dataCacheNum)
  {
    this.dataCacheNum = dataCacheNum;
    cacheList = new ArrayList<String>(dataCacheNum);
  }
tm()方法,我测试了一下,觉得这里并没有瓶颈。我用 tm 方法测试了 10万条数据,耗时 47 ms. 100W条数据也是470ms,一秒都不到。

输出到同一个文件也需要用到锁或者队列,也还是瓶颈。

其他的优化方法就靠大家提意见了,平均每秒写文件现在应该有1M多,每20分之一秒不止处理1万条数据。

呵呵,我们进行过一次数据处理比赛,大概处理量1.8g数据,进行大量计算,数据都在网络共享盘上,处理完毕也就21秒左右。
线程数不是越多越好,我当时是开的和CPU数一样的。
另外磁盘写入在你这里根本不是瓶颈,一般来说写入40m左右都是正常的。
我当时处理的时候连string类都是自己重写过的。
所以就你现在的计算量写入量,可能你连瓶颈在哪里都没有找到。
人们总是认为自己已经到极限了,但是却总是高估了自己解决问题的能力。
所以,亲,我给你的留言是任重而道远。
2014/01/25 19:38
回复
举报
大致看了下,浓浓的js风格。13
有几个问题:
1.callback使用不当。callback在js中最大的作用是异步执行,Java对应的概念是runnable。这里readline之后用callback,但是是同步执行的,所以意义不大。
2.多线程使用不当。唯一多线程的地方,你一进去就加了把锁,这样子根本多线程不起来是吧?反而加到了线程切换和锁竞争的开销。
3.readline倒是没有太大问题,我觉得最大的优化点在BufferedReader/Writer,这两个流默认的Buffer size都不大(8192b),你可以用"new BufferedWriter(new OutputStreamWriter(new FileOutputStream(sqlFile, true), "UTF-8"),size)"再试一下。应该会有一些提升。
2014/01/25 10:31
回复
举报
linapex博主

引用来自“哈库纳”的评论

引用来自“linapex”的评论

引用来自“哈库纳”的评论

昨天小试了一下,根据你的SQL模板生成1000W条SQL并写入文件共计 1.6G 的文件体积,大概耗时2~3分钟。
然后抛去写文件操作根据SQL模板用“sql.replaceAll(":\\d+", "aaa")”的查找替换方法拼接 SQL 大概用了 1分10秒,分析一下 replaceAll 这个方法用了正则表达式,是效率低下的主要原因。
以上测试结果是单线程下。

悠悠然然 提到的提升10倍不敢确定,不过5倍提升应该不是问题了把。
这个程序主要面临的问题还是 IO,多线程这块完全是个花瓶。此外 博主用到了 “锁”,锁也是一个很占 IO 的东西。

没有看懂,如何进行测试的。

多线程操作就是争抢那把锁,其实也只有一个线程在完成写操作.

提升10倍效率不敢想,5倍可能?能否贴贴代码?

程序瓶颈主要是IO问题,多线程这块用处可大了,每个线程处理自己的数据,最后归并啊,多线程资源分配啊,很多可以扩展的点。

刚才读取一个 1.85G的CSV格式的文件,耗时 199320 ms,3分钟左右。测试代码是经过优化过后的,在这里: http://my.oschina.net/u/1017195/blog/195508

5倍是个估量结果,现在的执行效率比上一个版本已经快出很多了。仍然3分钟的时间,处理数据的能力提升了至少2倍了把?
---------------
你这里代码还有很多可优化点,首先 ArrayList 初始大小好像只有10,当超过 10个元素之后它会自动扩大,这个操作会引发 ArrayList 内部把数组重新拷贝一次。建议直接把它的初始大小就设置成缓存的大小。
----------------------
或者干脆放弃 ArrayList 改为每个线程一个使用 ByteArrayOutputStream 作为输出缓存。缓存满了就排队写文件,用ByteArrayOutputStream 好处是你可以有机会把在 tm 方法中的 StringBuilder 去掉。

当然优化掉 StringBuilder 或许还有别的办法。

祝你好运

已经设置成了 数据缓存大小。

final WriteSqlHandle2 writeSqlFile = new WriteSqlHandle2(DATACACHENUM);
public WriteSqlHandle2(int dataCacheNum)
  {
    this.dataCacheNum = dataCacheNum;
    cacheList = new ArrayList<String>(dataCacheNum);
  }
tm()方法,我测试了一下,觉得这里并没有瓶颈。我用 tm 方法测试了 10万条数据,耗时 47 ms. 100W条数据也是470ms,一秒都不到。

输出到同一个文件也需要用到锁或者队列,也还是瓶颈。

其他的优化方法就靠大家提意见了,平均每秒写文件现在应该有1M多,每20分之一秒不止处理1万条数据。

2014/01/24 17:02
回复
举报

引用来自“linapex”的评论

引用来自“哈库纳”的评论

昨天小试了一下,根据你的SQL模板生成1000W条SQL并写入文件共计 1.6G 的文件体积,大概耗时2~3分钟。
然后抛去写文件操作根据SQL模板用“sql.replaceAll(":\\d+", "aaa")”的查找替换方法拼接 SQL 大概用了 1分10秒,分析一下 replaceAll 这个方法用了正则表达式,是效率低下的主要原因。
以上测试结果是单线程下。

悠悠然然 提到的提升10倍不敢确定,不过5倍提升应该不是问题了把。
这个程序主要面临的问题还是 IO,多线程这块完全是个花瓶。此外 博主用到了 “锁”,锁也是一个很占 IO 的东西。

没有看懂,如何进行测试的。

多线程操作就是争抢那把锁,其实也只有一个线程在完成写操作.

提升10倍效率不敢想,5倍可能?能否贴贴代码?

程序瓶颈主要是IO问题,多线程这块用处可大了,每个线程处理自己的数据,最后归并啊,多线程资源分配啊,很多可以扩展的点。

刚才读取一个 1.85G的CSV格式的文件,耗时 199320 ms,3分钟左右。测试代码是经过优化过后的,在这里: http://my.oschina.net/u/1017195/blog/195508

5倍是个估量结果,现在的执行效率比上一个版本已经快出很多了。仍然3分钟的时间,处理数据的能力提升了至少2倍了把?
---------------
你这里代码还有很多可优化点,首先 ArrayList 初始大小好像只有10,当超过 10个元素之后它会自动扩大,这个操作会引发 ArrayList 内部把数组重新拷贝一次。建议直接把它的初始大小就设置成缓存的大小。
----------------------
或者干脆放弃 ArrayList 改为每个线程一个使用 ByteArrayOutputStream 作为输出缓存。缓存满了就排队写文件,用ByteArrayOutputStream 好处是你可以有机会把在 tm 方法中的 StringBuilder 去掉。

当然优化掉 StringBuilder 或许还有别的办法。

祝你好运
2014/01/24 16:51
回复
举报
linapex博主

引用来自“哈库纳”的评论

昨天小试了一下,根据你的SQL模板生成1000W条SQL并写入文件共计 1.6G 的文件体积,大概耗时2~3分钟。
然后抛去写文件操作根据SQL模板用“sql.replaceAll(":\\d+", "aaa")”的查找替换方法拼接 SQL 大概用了 1分10秒,分析一下 replaceAll 这个方法用了正则表达式,是效率低下的主要原因。
以上测试结果是单线程下。

悠悠然然 提到的提升10倍不敢确定,不过5倍提升应该不是问题了把。
这个程序主要面临的问题还是 IO,多线程这块完全是个花瓶。此外 博主用到了 “锁”,锁也是一个很占 IO 的东西。

没有看懂,如何进行测试的。

多线程操作就是争抢那把锁,其实也只有一个线程在完成写操作.

提升10倍效率不敢想,5倍可能?能否贴贴代码?

程序瓶颈主要是IO问题,多线程这块用处可大了,每个线程处理自己的数据,最后归并啊,多线程资源分配啊,很多可以扩展的点。

刚才读取一个 1.85G的CSV格式的文件,耗时 199320 ms,3分钟左右。测试代码是经过优化过后的,在这里: http://my.oschina.net/u/1017195/blog/195508
2014/01/24 14:39
回复
举报
linapex博主

引用来自“悠悠然然”的评论

引用来自“linapex”的评论

引用来自“悠悠然然”的评论

呵呵,@ 我了,不回一下不好意思。
1.包名起得不好-test.com.linapex.room;
2.ZhengzeValidate类名起得不好
3.载入CSV效率太差了。
4.CallBack的call方法写得太垃....
5.tm方法写得太垃,效率太低
6.WriteSqlFile2类写得太垃,有严重的逻辑问题,静态对象+普通方法...反模式
7.异常用得不好

光看这个代码,效率再提高10倍问题不大,我们这边人写成这个样子,要请客吃饭的。
总之,低级别的代码。
呵呵,打击一下,谁让你抄这多人呢?

@了很多人,影响到你了,真是不好意思。

3.载入CSV效率太差了。
--你指的是更快的方法应该是,NIO,与文件内存映射吧。感觉没有IO操作方便.
4.CallBack的call方法写得太垃....
--这个我不太知道你指的原因是
5.tm方法写得太垃,效率太低
|--必须要承认~~因为平常用到只是几个参数的替换,对性能影响不大.jdk又不支持..
6.WriteSqlFile2类写得太垃,有严重的逻辑问题,静态对象+普通方法...反模式
|--当时写代码,为了方便快捷,写了很多静态的东东
7.异常用得不好
|--这个必须要承认~ 一般不太关注异常这东西.

效率再高10倍 估计是指NIO的东西了吧。。。
今天年会,跟领导喝了白的~~~ 回家改进了下代码,你看看如何~~ 包名,类名就没关系了,在我的测试项目,有时候写一些小工具,自己平常用的.

NIO与这个没有关系。
内存映射首次访问性能提升不大。
说你CSV读入效率太差,是指你用的是行读方式,行读是效率比较慢的一种读法。
call方法,一个方法里写了许多的内容,而且关系了许多个方面的内容,别人读起来太困难。
效率再高10倍,就是说你现在写的代码进行一定的优化,就可以提高10倍以上的效率。
另外你说的原来用单线程需要几个小时,用多线程就2-3分钟了,这个也不符合一般常理,有夸大之嫌。
比如你计算机是4核心,多线程比单线程也就最多提升3.x倍,接近于4倍而已。
任重而道远......

说你CSV读入效率太差,是指你用的是行读方式,行读是效率比较慢的一种读法。
|--参考:http://my.oschina.net/u/1017195/blog/195502
call方法,一个方法里写了许多的内容,而且关系了许多个方面的内容,别人读起来太困难。
|--据我所知,guava io也是这样写的吧。
code:Files.readLines(new File(PATH),Charsets.UTF_8,new LineProcessor<Object>() {
public boolean processLine(String line) throws IOException {
if(line==null)return false;
if(line.indexOf("包含的字")!=-1){
count++;
System.out.println(line);
}
if(count<2000 ){
return true;
}
return false;
}

效率再高10倍,就是说你现在写的代码进行一定的优化,就可以提高10倍以上的效率。
|--高10倍的效率不敢想,不过我今天早上改动了一下,读取332M CSV文件只需要30秒了,再提高10倍的话~~NB到极限了,新写了一篇博客:http://my.oschina.net/u/1017195/blog/195508
另外你说的原来用单线程需要几个小时,用多线程就2-3分钟了,这个也不符合一般常理,有夸大之嫌。
|--我说跑了一下午,挂在那里,没有太注意,不过时间确实有点久。 多线程跑其实有用锁,锁住了只有一个线程在里面添加内容,如果10个线程都写自己的sql文件,最后再将sql文件整合成一个大文件应该效率会更高。
2014/01/24 13:31
回复
举报
昨天小试了一下,根据你的SQL模板生成1000W条SQL并写入文件共计 1.6G 的文件体积,大概耗时2~3分钟。
然后抛去写文件操作根据SQL模板用“sql.replaceAll(":\\d+", "aaa")”的查找替换方法拼接 SQL 大概用了 1分10秒,分析一下 replaceAll 这个方法用了正则表达式,是效率低下的主要原因。
以上测试结果是单线程下。

悠悠然然 提到的提升10倍不敢确定,不过5倍提升应该不是问题了把。
这个程序主要面临的问题还是 IO,多线程这块完全是个花瓶。此外 博主用到了 “锁”,锁也是一个很占 IO 的东西。
2014/01/24 09:36
回复
举报

引用来自“linapex”的评论

引用来自“悠悠然然”的评论

呵呵,@ 我了,不回一下不好意思。
1.包名起得不好-test.com.linapex.room;
2.ZhengzeValidate类名起得不好
3.载入CSV效率太差了。
4.CallBack的call方法写得太垃....
5.tm方法写得太垃,效率太低
6.WriteSqlFile2类写得太垃,有严重的逻辑问题,静态对象+普通方法...反模式
7.异常用得不好

光看这个代码,效率再提高10倍问题不大,我们这边人写成这个样子,要请客吃饭的。
总之,低级别的代码。
呵呵,打击一下,谁让你抄这多人呢?

@了很多人,影响到你了,真是不好意思。

3.载入CSV效率太差了。
--你指的是更快的方法应该是,NIO,与文件内存映射吧。感觉没有IO操作方便.
4.CallBack的call方法写得太垃....
--这个我不太知道你指的原因是
5.tm方法写得太垃,效率太低
|--必须要承认~~因为平常用到只是几个参数的替换,对性能影响不大.jdk又不支持..
6.WriteSqlFile2类写得太垃,有严重的逻辑问题,静态对象+普通方法...反模式
|--当时写代码,为了方便快捷,写了很多静态的东东
7.异常用得不好
|--这个必须要承认~ 一般不太关注异常这东西.

效率再高10倍 估计是指NIO的东西了吧。。。
今天年会,跟领导喝了白的~~~ 回家改进了下代码,你看看如何~~ 包名,类名就没关系了,在我的测试项目,有时候写一些小工具,自己平常用的.

NIO与这个没有关系。
内存映射首次访问性能提升不大。
说你CSV读入效率太差,是指你用的是行读方式,行读是效率比较慢的一种读法。
call方法,一个方法里写了许多的内容,而且关系了许多个方面的内容,别人读起来太困难。
效率再高10倍,就是说你现在写的代码进行一定的优化,就可以提高10倍以上的效率。
另外你说的原来用单线程需要几个小时,用多线程就2-3分钟了,这个也不符合一般常理,有夸大之嫌。
比如你计算机是4核心,多线程比单线程也就最多提升3.x倍,接近于4倍而已。
任重而道远......

2014/01/24 08:42
回复
举报
linapex博主

引用来自“悠悠然然”的评论

呵呵,@ 我了,不回一下不好意思。
1.包名起得不好-test.com.linapex.room;
2.ZhengzeValidate类名起得不好
3.载入CSV效率太差了。
4.CallBack的call方法写得太垃....
5.tm方法写得太垃,效率太低
6.WriteSqlFile2类写得太垃,有严重的逻辑问题,静态对象+普通方法...反模式
7.异常用得不好

光看这个代码,效率再提高10倍问题不大,我们这边人写成这个样子,要请客吃饭的。
总之,低级别的代码。
呵呵,打击一下,谁让你抄这多人呢?

@了很多人,影响到你了,真是不好意思。

3.载入CSV效率太差了。
--你指的是更快的方法应该是,NIO,与文件内存映射吧。感觉没有IO操作方便.
4.CallBack的call方法写得太垃....
--这个我不太知道你指的原因是
5.tm方法写得太垃,效率太低
|--必须要承认~~因为平常用到只是几个参数的替换,对性能影响不大.jdk又不支持..
6.WriteSqlFile2类写得太垃,有严重的逻辑问题,静态对象+普通方法...反模式
|--当时写代码,为了方便快捷,写了很多静态的东东
7.异常用得不好
|--这个必须要承认~ 一般不太关注异常这东西.

效率再高10倍 估计是指NIO的东西了吧。。。
今天年会,跟领导喝了白的~~~ 回家改进了下代码,你看看如何~~ 包名,类名就没关系了,在我的测试项目,有时候写一些小工具,自己平常用的.

2014/01/23 22:40
回复
举报
前面写过一篇文章:
http://my.oschina.net/tinyframework/blog/193864
你犯的毛病比@老枪 还多,下次记得少抄些人,呵呵,尤其慎重抄我。
2014/01/23 19:36
回复
举报
更多评论
打赏
13 评论
17 收藏
0
分享
返回顶部
顶部