Linux下常用缩写

12:41:00 PM 0 Comments


 Linux下常用缩写



/bin = BINaries
/dev = DEVices
/etc = ETCetera
/lib = LIBrary
/proc = PROCesses
/sbin = Superuser BINaries
/tmp = TeMPorary
/usr = Unix Shared Resources
/var = VARiable ?
FIFO = First In, First Out
GRUB = GRand Unified Bootloader
IFS = Internal Field Seperators
LILO = LInux LOader
MySQL = My是最初作者女儿的名字，SQL = Structured Query Language
PHP = Personal Home Page Tools = PHP Hypertext Preprocessor
PS = Prompt String
Perl = "Pratical Extraction and Report Language" = "Pathologically Eclectic Rubbish Lister"
Python 得名于电视剧Monty Python's Flying Circus
Tcl = Tool Command Language
Tk = ToolKit
VT = Video Terminal
YaST = Yet Another Setup Tool
apache = "a patchy" server
apt = Advanced Packaging Tool
ar = archiver
as = assembler
awk = "Aho Weiberger and Kernighan" 三个作者的姓的第一个字母
bash = Bourne Again SHell
bc = Basic (Better) Calculator
bg = BackGround
biff = 作者Heidi Stettner在U.C.Berkely养的一条狗,喜欢对邮递员汪汪叫。
cal = CALendar
cat = CATenate
cd = Change Directory
chgrp = CHange GRouP
chmod = CHange MODe
chown = CHange OWNer
chsh = CHange SHell
cmp = compare
cobra = Common Object Request Broker Architecture
comm = common
cp = CoPy
cpio = CoPy In and Out
cpp = C Pre Processor
cron = Chronos 希腊文时间
cups = Common Unix Printing System
cvs = Current Version System
daemon = Disk And Execution MONitor
dc = Desk Calculator
dd = Disk Dump
df = Disk Free
diff = DIFFerence
dmesg = diagnostic message
du = Disk Usage
ed = editor
egrep = Extended GREP
elf = Extensible Linking Format
elm = ELectronic Mail
emacs = Editor MACroS
eval = EVALuate
ex = EXtended
exec = EXECute
fd = file descriptors
fg = ForeGround
fgrep = Fixed GREP
fmt = format
fsck = File System ChecK
fstab = FileSystem TABle
fvwm = F*** Virtual Window Manager
gawk = GNU AWK
gpg = GNU Privacy Guard
groff = GNU troff
hal = Hardware Abstraction Layer
joe = Joe's Own Editor
ksh = Korn SHell
lame = Lame Ain't an MP3 Encoder
lex = LEXical analyser
lisp = LISt Processing = Lots of Irritating Superfluous Parentheses
ln = LiNk
lpr = Line PRint
ls = list
lsof = LiSt Open Files
m4 = Macro processor Version 4
man = MANual pages
mawk = Mike Brennan's AWK
mc = Midnight Commander
mkfs = MaKe FileSystem
mknod = MaKe NODe
motd = Message of The Day
mozilla = MOsaic GodZILLa
mtab = Mount TABle
mv = MoVe
nano = Nano's ANOther editor
nawk = New AWK
nl = Number of Lines
nm = names
nohup = No HangUP
nroff = New ROFF
od = Octal Dump
passwd = PASSWorD
pg = pager
pico = PIne's message COmposition editor
pine = "Program for Internet News & Email" = "Pine is not Elm"
ping = 拟声 又 = Packet InterNet Grouper
pirntcap = PRINTer CAPability
popd = POP Directory
pr = pre
printf = PRINT Formatted
ps = Processes Status
pty = pseudo tty
pushd = PUSH Directory
pwd = Print Working Directory
rc = runcom = run command, rc还是plan9的shell
rev = REVerse
rm = ReMove
rn = Read News
roff = RunOFF
rpm = RPM Package Manager = RedHat Package Manager
rsh, rlogin, rvim中的r = Remote
rxvt = ouR XVT
seamoneky = 我
sed = Stream EDitor
seq = SEQuence
shar = SHell ARchive
slrn = S-Lang rn
ssh = Secure SHell
ssl = Secure Sockets Layer
stty = Set TTY
su = Substitute User
svn = SubVersioN
tar = Tape ARchive
tcsh = TENEX C shell
tee = T (T形水管接口)
telnet = TEminaL over Network
termcap = terminal capability
terminfo = terminal information
tex = τ?χνη的缩写，希腊文art
tr = traslate
troff = Typesetter new ROFF
tsort = Topological SORT
tty = TeleTYpewriter
twm = Tom's Window Manager
tz = TimeZone
udev = Userspace DEV
ulimit = User's LIMIT
umask = User's MASK
uniq = UNIQue
vi = VIsual = Very Inconvenient
vim = Vi IMproved
wall = write all
wc = Word Count
wine = WINE Is Not an Emulator
xargs = eXtended ARGuments
xdm = X Display Manager
xlfd = X Logical Font Description
xmms = X Multimedia System
xrdb = X Resources DataBase
xwd = X Window Dump
yacc = yet another compiler compiler

Java编程中“为了性能”尽量要做到的一些地方

8:08:00 PM 0 Comments



1. 尽量在合适的场合使用单例
 
使用单例可以减轻加载的负担，缩短加载的时间，提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面：
第一，控制资源的使用，通过线程同步来控制资源的并发访问；
第二，控制实例的产生，以达到节约资源的目的；
第三，控制数据共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。

2. 尽量避免随意使用静态变量
 
要知道，当某个对象被定义为stataic变量所引用，那么gc通常是不会回收这个对象所占有的内存，如
1 public class A{
2    static B b = new B();
3 }
此时静态变量b的生命周期与A类同步，如果A类不会卸载，那么b对象会常驻内存，直到程序终止。
3. 尽量避免过多过常的创建Java对象
 
尽量避免在经常调用的方法，循环中new对象，由于系统不仅要花费时间来创建对象，而且还要花时间对这些对象进行垃圾回收和处理，在我们可以控制的范围内，最大限度的重用对象，最好能用基本的数据类型或数组来替代对象。
 
4. 尽量使用final修饰符
 
带有final修饰符的类是不可派生的。在Java核心API中，有许多应用final的例子，例如java.lang.String。为String类指定final防止了使用者覆盖length()方法。另外，如果一个类是final的，则该类所有方法都是final的。Java编译器会寻找机会内联（inline）所有的final方法（这和具体的编译器实现有关）。此举能够使性能平均提高50%。
 
5. 尽量使用局部变量
 
调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快。其他变量，如静态变量、实例变量等，都在堆（Heap）中创建，速度较慢。
6. 尽量处理好包装类型和基本类型两者的使用场所
 
虽然包装类型和基本类型在使用过程中是可以相互转换，但它们两者所产生的内存区域是完全不同的，基本类型数据产生和处理都在栈中处理，包装类型是对象，是在堆中产生实例。
在集合类对象，有对象方面需要的处理适用包装类型，其他的处理提倡使用基本类型。
7. 慎用synchronized，尽量减小synchronize的方法
 
都知道，实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。synchronize方法被调用时，直接会把当前对象锁 了，在方法执行完之前其他线程无法调用当前对象的其他方法。所以synchronize的方法尽量小，并且应尽量使用方法同步代替代码块同步。
8. 尽量使用StringBuilder和StringBuffer进行字符串连接
 
这个就不多讲了。
9. 尽量不要使用finalize方法
 
实际上，将资源清理放在finalize方法中完成是非常不好的选择，由于GC的工作量很大，尤其是回收Young代内存时，大都会引起应用程序暂停，所以再选择使用finalize方法进行资源清理，会导致GC负担更大，程序运行效率更差。
 
10. 尽量使用基本数据类型代替对象
 
String str = "hello";
上面这种方式会创建一个“hello”字符串，而且JVM的字符缓存池还会缓存这个字符串；
String str = new String("hello");
此时程序除创建字符串外，str所引用的String对象底层还包含一个char[]数组，这个char[]数组依次存放了h,e,l,l,o
 
11. 单线程应尽量使用HashMap、ArrayList
 
HashTable、Vector等使用了同步机制，降低了性能。
 
12. 尽量合理的创建HashMap
 
当你要创建一个比较大的hashMap时，充分利用另一个构造函数
public HashMap(int initialCapacity, float loadFactor)
避免HashMap多次进行了hash重构,扩容是一件很耗费性能的事，在默认中initialCapacity只有16，而loadFactor是 0.75，需要多大的容量，你最好能准确的估计你所需要的最佳大小，同样的Hashtable，Vectors也是一样的道理。
 
13. 尽量减少对变量的重复计算
 
如
for(int i=0;i
应该改为
for(int i=0,len=list.size();i
并且在循环中应该避免使用复杂的表达式，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。
 
14. 尽量避免不必要的创建
 
如
A a = new A();
if(i==1){list.add(a);}
应该改为
if(i==1){
A a = new A();
list.add(a);}
 
15. 尽量在finally块中释放资源
 
程序中使用到的资源应当被释放，以避免资源泄漏。这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。
 
16. 尽量使用移位来代替'a/b'的操作
 
"/"是一个代价很高的操作，使用移位的操作将会更快和更有效
如
int num = a / 4;
int num = a / 8;
应该改为
int num = a >> 2;
int num = a >> 3;
但注意的是使用移位应添加注释，因为移位操作不直观，比较难理解
 
17.尽量使用移位来代替'a*b'的操作
 
同样的，对于'*'操作，使用移位的操作将会更快和更有效
如
int num = a * 4;
int num = a * 8;
应该改为
int num = a << 2;
int num = a << 3;
 
18. 尽量确定StringBuffer的容量
 
StringBuffer 的构造器会创建一个默认大小（通常是16）的字符数组。在使用中，如果超出这个大小，就会重新分配内存，创建一个更大的数组，并将原先的数组复制过来，再 丢弃旧的数组。在大多数情况下，你可以在创建 StringBuffer的时候指定大小，这样就避免了在容量不够的时候自动增长，以提高性能。 
如：StringBuffer buffer = new StringBuffer(1000);
 
19. 尽量早释放无用对象的引用
 
大部分时，方法局部引用变量所引用的对象 会随着方法结束而变成垃圾，因此，大部分时候程序无需将局部，引用变量显式设为null。
例如：
1 Public void test(){
2    Object obj = new Object();
3    ……
4    Obj=null;
5 }
上面这个就没必要了，随着方法test()的执行完成，程序中obj引用变量的作用域就结束了。但是如果是改成下面：
1 Public void test(){
2    Object obj = new Object();
3    ……
4   Obj=null;
5    //执行耗时，耗内存操作；或调用耗时，耗内存的方法
6    ……
7 }
这时候就有必要将obj赋值为null，可以尽早的释放对Object对象的引用。
 
20. 尽量避免使用二维数组
 
二维数据占用的内存空间比一维数组多得多，大概10倍以上。
 
21. 尽量避免使用split
 
除非是必须的，否则应该避免使用split，split由于支持正则表达式，所以效率比较低，如果是频繁的几十，几百万的调用将会耗费大量资源，如果确实需 要频繁的调用split，可以考虑使用apache的StringUtils.split(string,char)，频繁split的可以缓存结果。
 
22. ArrayList & LinkedList
 
一 个是线性表，一个是链表，一句话，随机查询尽量使用ArrayList，ArrayList优于LinkedList，LinkedList还要移动指 针，添加删除的操作LinkedList优于ArrayList，ArrayList还要移动数据，不过这是理论性分析，事实未必如此，重要的是理解好2 者得数据结构，对症下药。
 
23. 尽量使用System.arraycopy ()代替通过来循环复制数组
 
System.arraycopy() 要比通过循环来复制数组快的多
 
24. 尽量缓存经常使用的对象
 
尽可能将经常使用的对象进行缓存，可以使用数组，或HashMap的容器来进行缓存，但这种方式可能导致系统占用过多的缓存，性能下降，推荐可以使用一些第三方的开源工具，如EhCache，Oscache进行缓存，他们基本都实现了FIFO/FLU等缓存算法。
 
25. 尽量避免非常大的内存分配
 
有时候问题不是由当时的堆状态造成的，而是因为分配失败造成的。分配的内存块都必须是连续的，而随着堆越来越满，找到较大的连续块越来越困难。
 
26. 慎用异常
 
当创建一个异常时，需要收集一个栈跟踪(stack track)，这个栈跟踪用于描述异常是在何处创建的。构建这些栈跟踪时需要为运行时栈做一份快照，正是这一部分开销很大。当需要创建一个 Exception 时，JVM 不得不说：先别动，我想就您现在的样子存一份快照，所以暂时停止入栈和出栈操作。栈跟踪不只包含运行时栈中的一两个元素，而是包含这个栈中的每一个元素。
如 果您创建一个 Exception ，就得付出代价。好在捕获异常开销不大，因此可以使用 try-catch 将核心内容包起来。从技术上讲，您甚至可以随意地抛出异常，而不用花费很大的代价。招致性能损失的并不是 throw 操作——尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。真正要花代价的是创建异常。幸运的是，好的编程习惯已教会我们，不应该不管三七二十一就 抛出异常。异常是为异常的情况而设计的，使用时也应该牢记这一原则。

copy constructors, assignment operators, and exception safe assignment

1:39:00 PM 0 Comments


What is a copy constructor?

A copy constructor is a special constructor for a class/struct that is
used to make a copy of an existing instance. According to the C++
standard, the copy constructor for MyClass must have one of the
following signatures:

1
2
3
4
  MyClass( const MyClass& other );
  MyClass( MyClass& other );
  MyClass( volatile const MyClass& other );
  MyClass( volatile MyClass& other );


Note that none of the following constructors, despite the fact that
they could do the same thing as a copy constructor, are copy
constructors:

1
2
  MyClass( MyClass* other );
  MyClass( const MyClass* other );


or my personal favorite way to create an infinite loop in C++:

 
  MyClass( MyClass other );


When do I need to write a copy constructor?

First, you should understand that if you do not declare a copy
constructor, the compiler gives you one implicitly. The implicit
copy constructor does a member-wise copy of the source object.
For example, given the class:

1
2
3
4
5
  class MyClass {
      int x;
      char c;
      std::string s;
  };


the compiler-provided copy constructor is exactly equivalent to:

1
2
3
  MyClass::MyClass( const MyClass& other ) :
     x( other.x ), c( other.c ), s( other.s )
  {}


In many cases, this is sufficient. However, there are certain
circumstances where the member-wise copy version is not good enough.
By far, the most common reason the default copy constructor is not
sufficient is because the object contains raw pointers and you need
to take a "deep" copy of the pointer. That is, you don't want to 
copy the pointer itself; rather you want to copy what the pointer
points to. Why do you need to take "deep" copies? This is 
typically because the instance owns the pointer; that is, the
instance is responsible for calling delete on the pointer at some
point (probably the destructor). If two objects end up calling
delete on the same non-NULL pointer, heap corruption results.

Rarely you will come across a class that does not contain raw
pointers yet the default copy constructor is not sufficient.
An example of this is when you have a reference-counted object.
boost::shared_ptr<> is example.

Const correctness

When passing parameters by reference to functions or constructors, be very
careful about const correctness. Pass by non-const reference ONLY if
the function will modify the parameter and it is the intent to change
the caller's copy of the data, otherwise pass by const reference.

Why is this so important? There is a small clause in the C++ standard
that says that non-const references cannot bind to temporary objects.
A temporary object is an instance of an object that does not have a
variable name. For example:

 
  std::string( "Hello world" );


is a temporary, because we have not given it a variable name. This
is not a temporary:

 
  std::string s( "Hello world" );


because the object's name is s.

What is the practical implication of all this? Consider the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
  // Improperly declared function:  parameter should be const reference:
  void print_me_bad( std::string& s ) {
      std::cout << s << std::endl;
  }

  // Properly declared function: function has no intent to modify s:
  void print_me_good( const std::string& s ) {
      std::cout << s << std::endl;
  }

  std::string hello( "Hello" );

  print_me_bad( hello );  // Compiles ok; hello is not a temporary
  print_me_bad( std::string( "World" ) );  // Compile error; temporary object
  print_me_bad( "!" ); // Compile error; compiler wants to construct temporary
                       // std::string from const char*

  print_me_good( hello ); // Compiles ok
  print_me_good( std::string( "World" ) ); // Compiles ok
  print_me_good( "!" ); // Compiles ok


Many of the STL containers and algorithms require that an object
be copyable. Typically, this means that you need to have the
copy constructor that takes a const reference, for the above
reasons.

What is an assignment operator?

The assignment operator for a class is what allows you to use
= to assign one instance to another. For example:

1
2
  MyClass c1, c2;
  c1 = c2;  // assigns c2 to c1


There are actually several different signatures that an
assignment operator can have:

(1) MyClass& operator=( const MyClass& rhs );
(2) MyClass& operator=( MyClass& rhs );
(3) MyClass& operator=( MyClass rhs );
(4) const MyClass& operator=( const MyClass& rhs );
(5) const MyClass& operator=( MyClass& rhs );
(6) const MyClass& operator=( MyClass rhs );
(7) MyClass operator=( const MyClass& rhs );
(8) MyClass operator=( MyClass& rhs );
(9) MyClass operator=( MyClass rhs );

These signatures permute both the return type and the parameter
type. While the return type may not be too important, choice
of the parameter type is critical.

(2), (5), and (8) pass the right-hand side by non-const reference,
and is not recommended. The problem with these signatures is that
the following code would not compile:

1
2
  MyClass c1;
  c1 = MyClass( 5, 'a', "Hello World" );  // assuming this constructor exists


This is because the right-hand side of this assignment expression is
a temporary (un-named) object, and the C++ standard forbids the compiler
to pass a temporary object through a non-const reference parameter.

This leaves us with passing the right-hand side either by value or
by const reference. Although it would seem that passing by const
reference is more efficient than passing by value, we will see later
that for reasons of exception safety, making a temporary copy of the
source object is unavoidable, and therefore passing by value allows
us to write fewer lines of code.

When do I need to write an assignment operator?

First, you should understand that if you do not declare an
assignment operator, the compiler gives you one implicitly. The
implicit assignment operator does member-wise assignment of 
each data member from the source object. For example, using
the class above, the compiler-provided assignment operator is
exactly equivalent to:

1
2
3
4
5
6
  MyClass& MyClass::operator=( const MyClass& rhs ) {
      x = other.x;
      c = other.c;
      s = other.s;
      return *this;
  }


In general, any time you need to write your own custom copy 
constructor, you also need to write a custom assignment operator.

What is meant by Exception Safe code?

A little interlude to talk about exception safety, because programmers
often misunderstand exception handling to be exception safety.

A function which modifies some "global" state (for example, a reference
parameter, or a member function that modifies the data members of its 
instance) is said to be exception safe if it leaves the global state
well-defined in the event of an exception that is thrown at any point
during the function.

What does this really mean? Well, let's take a rather contrived
(and trite) example. This class wraps an array of some user-specified
type. It has two data members: a pointer to the array and a number of 
elements in the array.

1
2
3
4
5
6
7
8
9
  template< typename T >
  class MyArray {
      size_t  numElements;
      T*      pElements;

    public:
      size_t count() const { return numElements; }
      MyArray& operator=( const MyArray& rhs );
  };


Now, assignment of one MyArray to another is easy, right?

1
2
3
4
5
6
7
8
9
10
11
  template<>
  MyArray::operator=( const MyArray& rhs ) {
      if( this != &rhs ) {
          delete [] pElements;
          pElements = new T[ rhs.numElements ];
          for( size_t i = 0; i < rhs.numElements; ++i )
              pElements[ i ] = rhs.pElements[ i ];
          numElements = rhs.numElements;
      }
      return *this;
  }


Well, not so fast. The problem is, the line

 
  pElements[ i ] = rhs.pElements[ i ];


could throw an exception. This line invokes operator= for type T, which
could be some user-defined type whose assignment operator might throw an
exception, perhaps an out-of-memory (std::bad_alloc) exception or some
other exception that the programmer of the user-defined type created.

What would happen if it did throw, say on copying the 3rd element of 10
total? Well, the stack is unwound until an appropriate handler is found. 
Meanwhile, what is the state of our object? Well, we've reallocated our
array to hold 10 T's, but we've copied only 2 of them successfully. The
third one failed midway, and the remaining seven were never even attempted
to be copied. Furthermore, we haven't even changed numElements, so whatever
it held before, it still holds. Clearly this instance will lie about the
number of elements it contains if we call count() at this point.

But clearly it was never the intent of MyArray's programmer to have count()
give a wrong answer. Worse yet, there could be other member functions that
rely more heavily (even to the point of crashing) on numElements being correct.
Yikes -- this instance is clearly a timebomb waiting to go off.

This implementation of operator= is not exception safe: if an exception is
thrown during execution of the function, there is no telling what the state
of the object is; we can only assume that it is in such a bad state (ie,
it violates some of its own invariants) as to be unusable. If the object is 
in a bad state, it might not even be possible to destroy the object without
crashing the program or causing MyArray to perhaps throw another exception. 
And we know that the compiler runs destructors while unwinding the stack to 
search for a handler. If an exception is thrown while unwinding the stack,
the program necessarily and unstoppably terminates.


How do I write an exception safe assignment operator?

The recommended way to write an exception safe assignment operator is via
the copy-swap idiom. What is the copy-swap idiom? Simply put, it is a two-
step algorithm: first make a copy, then swap with the copy. Here is our
exception safe version of operator=:

1
2
3
4
5
6
7
8
9
10
11
  template<>
  MyArray::operator=( const MyArray& rhs ) {
      // First, make a copy of the right-hand side
      MyArray tmp( rhs );

      // Now, swap the data members with the temporary:
      std::swap( numElements, tmp.numElements );
      std::swap( pElements, tmp.pElements );

      return *this;
  }


Here's where the difference between exception handling and exception safety
is important: we haven't prevented an exception from occurring; indeed,
the copy construction of tmp from rhs may throw since it will copy T's.
But, if the copy construction does throw, notice how the state of *this
has not changed, meaning that in the face of an exception, we can guarantee
that *this is still coherent, and furthermore, we can even say that it is
left unchanged.

But, you say, what about std::swap? Could it not throw? Yes and no. The
default std::swap<>, defined in  can throw, since std::swap<>
looks like this:

1
2
3
4
5
6
7
  template< typename T >
  swap( T& one, T& two )
  {
      T tmp( one );
      one = two;
      two = tmp;
  }


The first line runs the copy constructor of T, which can throw; the 
remaining lines are assignment operators which can also throw.

HOWEVER, if you have a type T for which the default std::swap() may result
in either T's copy constructor or assignment operator throwing, you are 
politely required to provide a swap() overload for your type that does not
throw. [Since swap() cannot return failure, and you are not allowed to throw,
your swap() overload must always succeed.] By requiring that swap does not 
throw, the above operator= is thus exception safe: either the object is 
completely copied successfully, or the left-hand side is left unchanged.

Now you'll notice that our implementation of operator= makes a temporary
copy as its first line of code. Since we have to make a copy, we might as
well let the compiler do that for us automatically, so we can change the
signature of the function to take the right-hand side by value (ie, a copy)
rather than by reference, and this allows us to eliminate one line of code:

1
2
3
4
5
6
  template<>
  MyArray::operator=( MyArray tmp ) {
      std::swap( numElements, tmp.numElements );
      std::swap( pElements, tmp.pElements );
      return *this;
  }
Subscribe to: Posts (Atom)